[fox88]

Neoo26, on 08 December 2012 - 12:37 AM, said:

and I had no time to read discussions about that

That's why people like you fall into the same potholes again and again. Awesome.

Neoo26, on 08 December 2012 - 12:37 AM, said:

Why I'm wasting my time there ?

You are trying to waste other's time.

Neoo26, on 08 December 2012 - 12:37 AM, said:

Yes, but I have no time to study english

It's your problem, not mine.

Neoo26, on 08 December 2012 - 12:37 AM, said:

About the transfer there is no better way than the torrent managment with very very small parts.

Stubborn repetition is not a proof.

Neoo26, on 08 December 2012 - 12:37 AM, said:

I know how eMule work better than you dude... believe me...

Kid's talk. Go impress your agemates.

This post has been edited by fox88: 08 December 2012 - 11:46 AM

[Neoo26]

Well hmmmm, first that is OT, second you don't know how many test I did with eMule and how many suggestion give to some modders, how many bug founds and tell how to fix. I said you don't know how eMule work? No cuz is obvious that you know. But if you don't understand that 9 mb before can upload data to others should be changed to have better result and speed up also short runners, well, I have nothing to say...

Offi eMule need ~50min to send a complete part. Before, the client that is downloading this part, can't upload anything. How can a network with that base be fast??

Seriously, I have no work to say here, if you (you @all) don't understand that.

3rd, I'm tired, I don't want waste my time here anymore. You don't proof anything because only say "NO!" to suggestion without prove that your explanation is right while who suggest say why it should be better with some comparision and example (and simply logic).

Bye Bye.

[fox88]

Neoo26, on 09 December 2012 - 03:01 AM, said:

But if you don't understand that 9 mb before can upload data to others should be changed to have better result and speed up also short runners, well, I have nothing to say...

Make sure the word compatibility if meaningful for you in the first place.
I repeat for the third and the last time: so called your idea is years old. It was discussed a number of times in this forum. I'm not going to do searches for you nor repeat the explanations.
I do not know who are short runners, no comments hence.

Neoo26, on 09 December 2012 - 03:01 AM, said:

Offi eMule need ~50min to send a complete part. Before, the client that is downloading this part, can't upload anything. How can a network with that base be fast??

For a user who has nothing to share and for the very first part that's correct. Situation is more complicated in real life.
For example, 50 min is the time for 3KB/s slot. It implies very slow connection: dial-up or "smart" user have set 10KB/s upload limit. Now, have you ever seen a fast dial-up network?
It's better with faster connections (and therefore - wider slots). Do not forget about 30 min reask timer and queue waiting time which makes 50 min not that evil. And so on.

[Neoo26]

Right I forgot the reask times, that system also should be changed torrent like IMHO. Yes, it's more overhead but more efficently.

Btw, there is no reason to keep discuss here, I understood that you don't want change nothing. I'll do search and see result of discssion about NAT-T etc. But I think you didn't proof nothing cuz you can't proof wrong things.

[fox88]

Neoo26, on 09 December 2012 - 03:07 PM, said:

Yes, it's more overhead but more efficently.

More math: efficiency depends on criterion. You must define the criterion first.

Neoo26, on 09 December 2012 - 03:07 PM, said:

there is no reason to keep discuss here

You did not really discuss.

Neoo26, on 09 December 2012 - 03:07 PM, said:

I understood that you don't want change nothing

Heh. If I don't, then do you want to change nothing?
Anyway, your understanding is wrong.

Neoo26, on 09 December 2012 - 03:07 PM, said:

I'll do search and see result of discssion about NAT-T etc.

Finally. It should have been a starting point.

Neoo26, on 09 December 2012 - 03:07 PM, said:

But I think you didn't proof nothing cuz you can't proof wrong things.

I do not care what you think or what you declare without a proof.

[Neoo26]

I did some explanation about my ideas (david also), and all here without proof said just no. You call this discuss ? Nah, that's not how should work.

BYE

[fox88]

Neoo26, on 09 December 2012 - 05:31 PM, said:

You call this discuss ?

No, you called.

[sonoro]

@fox88

Proof you with your math pathetic he is wrong!

[stoatwblr]

Some Support, on 09 February 2012 - 10:41 AM, said:

eMule has already that kind of protection, but when an attacker starts to have thousend - millions of IPs at hand, there is no easy response. Sure you could block the whole IP range, but that isn't really a solution to the problem.

For Attack Mitigation purposes, blocking per /64 is a perfectly reasonable compromise - the reason being that this is the minimum allocation an ISP will hand to an enduser.

ie: Anything in the same /64 is highly likely to be on the same LAN.

[Sir_Boagalott]

Heres my 2 cents:

IMHO the devs should rel a new version and heres why: when end users see a program like this and its not getting updated regularily they get the "impression" that the devs no longer care and "assume" that the project is basically dead. Keep in mind that it doesnt matter if what the masses believe is actually true, they think it is regardless, and the actual truth escapes them. It definitely matters what the masses "think" because they will act on their beliefs even if they arent true, they believe it to be correct and will take wrong actions based on their incorrect beliefs.

I understand that when a new official version is rel all the time and effort that goes into it. The devs have to do to put it out, and then all the time that the poor modders have to do to update to the new version, especially when the new version has major changes. Theres not a lot of activity now so how many of the modders still have the time to update to a new version just for the sake of putting out a new version to keep the masses happy?

What I would love to see is a new eMule 50b with just simple bug fixes (no huge major changes) that basically all the current mods have already implemented. If the majority of mods already have these bug fixes, if a 50b was to come out instead of having to add all of their mod features to new 50b it would be easier to add the few 50b changes to their existing 50a srcs and then just change the client string to 50b. ta-da!!

I realize that traditionally this is not how its done, but with the lack of interest from what it used to be it would make more sense to rethink how its done to make it easier for everybody involved just for the purpose of keeping the project in active status. KISS - keep it super simple

That way the devs are happy, not tonnes of work, the modders are happy, not tonnes of work, and all the end users are happy knowing for sure that the project is still being developed.

If/when the devs want to rel a new ver with lots of changes update the ver to eMule 51a.