*Upload disconnects and TCP
 

From Shareaza 1.2 (?):

"Better upload limiting. Shareaza always supported limiting the number of total uploads and the number per unique host, which provided good protection. However some clients can be very aggressive and send frequent requests without closing their old connections. Shareaza now has additional measures to limit not only the number of active transfers per host, but also throttle the number of raw connections. "

Mike, I want to point out the following scenario that we observed in house:

- A client connects to an HTTP server and requests a file

- At some point the TCP connection is severed

- The client becomes aware of the disconnect before the server

- Client re-connects to the server and re-requests the file

- At this point, the server sees two connections from the same client

We have a fairly complex strategy for detecting this situation and handling it gracefully. When the second connection comes in, we wait for the request and compare it to the first connection. The first connection is put on "probation".

One characteristic of broken connections is they never send or receive any data. If a connection on "probation" sees a byte go in or out then we take it off probation and drop the newer duplicate. If the newer duplicate completes data transfer, and its request exactly matches the older connection's request, then we drop the older one.

There is a lot more logic (to handle n slots per host) but this is the basic idea.

Obviously, if we did away with upload slots (like a standard web server) this problem is a non-issue.

Cheers Vinnie, yes I agree that scheme has some benefits and could perhaps differentiate between clients which are reestablishing lost downloads quickly and those which are actually malicious.

I will implement something along those lines in the next release.