Jump to content

A simple proposal to solve the ratio problem ??


zigmund

Recommended Posts

In order to update my ratio, Demonoid (and other trackers), need to know my identity and IP address before the "event=stopped" is sent to the tracker.

With dynamic allocation of IP addresses (as opposed to static) I have to login to Demonoid to update my IP address.

So (if like MailWasher and FTP Pro) I could put my Demonoid username and password into uTorrent, it could login to Demonoid and logout. This would update my current IP address (at the moment I have to do this manually), then, the "event=stopped" messages would link by IP address to my Demonoid identity, and my ratio would be correctly updated.

Having to login to Demonoid manually, to update my IP address, so as to get my ratio correctly updated, though it works, seems archaic, when it could be done automatically by my uTorrent client. Having such a facility in uTorrent wouldn't affect trackers other than Demonoid, or those that work in a similar manner. It would be an addition to extend uTorrent not a fundamental change.

There are other improvements I could suggest to improve updating ratios, but one suggestion at a time.

Over successive days my ratio has been 1.15, 1.11, 1.17, 0.83, 0.88, 0.90, 1.02, so I've cracked the updating by logging into Demonoid just before the event message is sent.

A varient of my proposal would be if I could put my unique Demonoid name in my client, and it could send it to (or be interrogated for) by Demonoid and other trackers. If other trackers don't choose to conform, then that's their problem, but there is no reason why, if they want to track ratios the Demonoid way, it shouldn't work for them. Just sending my unique identity doesn't even involve logging in or sending passwords. It would be "What's your name" and combining it with the amount uploaded and reporting this to the ratio accounting machine, which in the case of Demonoid, is run by them and is part of their network.

Link to comment
Share on other sites

This idea is even more specific than your previous request. µTorrent has no "ratio problem"; Demonoid does. Needing to log into a tracker isn't something a torrent client should have to deal with -- again, that's a tracker specific issue. Tracker statistics don't update only on exit -- statistics get updated every time you announce to the tracker, so I'm not sure why you're so focused on the very last stop event.

Note: I'm really not trying to put your ideas down in any way; I just don't see why a torrent client needs to shape it self to conform to and deal with a problem you're having with one tracker (or even just a few trackers).

Link to comment
Share on other sites

Note: I'm really not trying to put your ideas down in any way; I just don't see why a torrent client needs to shape it self to conform to and deal with a problem you're having with one tracker (or even just a few trackers).

I'm aware that some membership torrent communities try to track ratios; whilst saying publicly that ratios don't matter so long as you give back as much as, or more, than you take, and that you won't be deregistered for poor ratio. A sentiment I endorse.

But I can't help notice the flood of posts about ratio problems. What I would like to see is a method of ensuring ratios are updated accurately. Adding a facility to link your identity to your current IP address seems like a worthwhile feature, and would not seem to involve any addition to or change in protocols. It would only involve an extension to uTorrent as part of the evolutionary process.

If tracking ratios is desirable, or considered by some important, lets try to get it right, and make it as foolproof as possible.

My personal gripe is that I have 12 seeding torrents, all but 2 with ratios in the low 10's, in some cases I seem to be the only one with 100%, yet my reported ratio doesn't reflect this. I just got into the ratio issue by trying to find out why, in the process discovering that many in the BT community have ratio reporting problems.

I'm not particularly focused on the stop event except insofar as it's associated with ratio reporting, and as far as I can judge ratio is computed incrementally, not by your client reporting absolute ratios for each torrent. If ratios were reported in absolute values (uploaded/downloaded for each torrent) there would be no problem, if an update of ratio got lost, the next would update the absolute value.

In this thread I'm just raising a proposal that hopefully might reach the ears of the uTorrent developer/maintainer. If people get credit for being good members of the community it might encourage others to follow their example.

Link to comment
Share on other sites

Ratio tracking isn't necessarily desirable. The fact of the matter is, BitTorrent was never designed with ratio tracking and private trackers in mind; rather, it was designed with openness in mind. All of these private trackers that sprung up did so after the fact -- after BitTorrent was already created. Demonoid is infamous for having a busted ratio tracker, and it's not a problem that plagues most other private trackers. Again, they have their own set of problems to solve before any client should start working around them. Other trackers already have it right -- why can't Demonoid get it right?

Changing µTorrent for Demonoid's sake is like trying to make an inkjet printer (µTorrent) print on a piece of wood (Demonoid) -- there are other papers (trackers) out there that allow the printer to print normally as it was designed to print (and there are special papers with templates pre-printed on them -- private trackers), so why should the printer be modified to work with that one piece of wood? Why can't the piece of wood be made like normal papers (or templates) that fit into and work perfectly with the printer?

FWIW, if people want to get private trackers "right," making arbitrary design decisions along the way, like forcing clients to log in or send a username, is hardly the way to go.

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...