Well, I'm trying to solve the request-management problem. The thing is, near the end of the download, you run out of requests, and then have two options - request same data from multiple clients, or drop the client (that ran out of requests) completely. Naturally, dropping clients results in last chunks of the file to come from some 28.8kbps modem, which ain't good. However, when requesting a chunk from multiple clients, you also need to start canceling requests as the data arrives, otherwise you just waste everyone's bandwidth with data you don't need anymore.

The idea was simple - whenever clients make requests, push them into a central requests structure in the corresponding Torrent, in a sequenced manner, so that the first request to be pushed shall be the bottom-most request in the structure. Now, when a client runs out of requests, it'll just take the bottom-most request in the Torrent (since that request has been waiting unanswered for the longest time), and send that request instead.

On the idea level, it all sounded nice, until I got to implementing it. Now we have a whole bunch of new problems - fast clients cause the shared-requests to rotate too fast, which means they compete with each other for the same requests. And to make it worse, as soon as I send single Cancel message to a client, it stops sending any new chunks at all - it sends the chunks that were requested prior to the cancel message, but requests made after that remain un-answered.

So far my attempts to understand Azureus source code, or find any kind of logic or structure in it have failed, (and Azureus accounts for like 95% of BT users), so I'm kinda lost (again). ShareAza and libtorrent code didn't give any hints towards that end either.

Madcat, ZzZz