Improve "event=stopped" flaws

[zigmund]

Over in the Demonoid forum there are an awful lot of postings about ratio not updating.

I can't find any reference to the content/format/programming of the event messages.

As far as I can determine the "event=stopped" message contains the amount uploaded, for each torrent, since the previous "event=started" message.

There are conditions for the stop message to be linked to the corresponding Demonoid account.

What is needed is an acknowledgement from the tracker to the uTorrent client that the "event=stopped" message has been received.

If the client doesn't receive this it should assume the stopped message hasn't been received, and the next "event=stopped" message should be the amount uploaded since the client was started, or if there is a prior "event=stopped" acknowledgement, the amount uploaded since then. Ratios would then be more accurate. Obviously there would be no problem with the client recording this locally.

Then provided the condition for the tracker being able to attribute the amount uploaded to the correct account is met, we would all get credited for the full amount uploaded (seeded) even if the odd "event=stopped" message didn't get through. The next event that got through would correct the error.

As far as I can see there is a flaw which can be corrected by adding feedback in the form of an acknowledgement to "event=stopped" messages.

[Ultima]

In the end, trackers aren't required to respond to stop events by the tracker specs, so what happens to all those other trackers that don't respond to stop events? Does that mean µTorrent will just keep piling up transfer statistics and sending the cumulative amount in every tracker announce? It'll just end up being µTorrent sending bad statistics to trackers, and being labeled as a cheating client.

Demonoid always seems to have problems with ratio tracking. Other trackers track user ratios perfectly fine, and it's not the job of a client to work around tracker problems, so I'm not really seeing why µTorrent needs to bend over its back to support a(n apparently) broken tracker -- the tracker is what needs fixing. Even if something like this were to happen, it would require that the tracker be modified to support sending responses -- why not fix the whole tracker instead of working around it?

IMHO.

[CodeRed]

The tracker probably should send back a reply until it has recorded the stats. When µTorrent gets an HTTP response it assumes it's finished. It doesn't linger, try again, double check, or assume there's a tracker bug. It simply disconnects. Maybe it's just faster to hang up than other clients since it might only care to see the header and ignores the body. I'd like to see some traces to indicate µTorrent doesn't send accurate stats.

[Firon]

Demonoid is horribly broken as far as stats tracking goes.