Jump to content

µtorrent and have piece messages


adtimg

Recommended Posts

Posted

The first thing I need to say is that I'm not going to dis anyone's favorite client. Ok?

I use Azureus and when I'm in a swarm, µtorrent clients v1.4.0 do not report have piece messages.

Their percentage remains at whatever it was when they first connected, there is also no reporting of upload speed or data received from others.

Ultimately, their ratio of data to me becomes onesided in µtorrent's favor. I'm not really happy about that and have kicked clients that aren't giving up better data rates in order to serve clients that are.

Nothing personal mind you, but I would prefer the share ratio to be more equal.

When seeding, however, I can "force" it to send me a have piece by being in superseed mode.

µtorrent clients will wait about 30 seconds before realizing they're not going to get anything else until they send one, and at this point all the stats begin to update in the expected manner.

So would this be considered a bug in µtorrent v1.4.0 or something else?

I haven't had any experience with v1.4.1beta clients yet

TimG

Posted

Also, the haves have no effect on performance. At all. Not even in the slightest. In fact, the BT spec itself says have messages are not reliable to measure anything, because they're so easily exploited (a malicious peer can send lots of HAVEs)

Posted

Also everyone should note that the faster you complete pieces, the more overhead have messages take towards seeds. All that overhead is away from your upload speed. Are you willing to sacrifice your upload just for some seeding users who stare at their peerlists all day long looking at your download speed and completed percentage?

Posted

Sorry to create such a stir, but when µtorrent 1.4.0 clients are connected to me and are not sending pieces to me to the tune of -3:1 ratio, I kick 'em.

Whether or not the BT spec requires a client to send a have is not the issue for me

Leechy behavior is, so a malicious client will eventually show itself and be banned by most private trackers.

I'd have never bothered to look into why µtorrent didn't send haves nor would I even care, were it not for the fact that leechy behavior goes against what the whole torrent thing is supposed to mean.

It's about sharing what you get right?

Perfect data values were not what I meant by wanting to know where a client stood in terms of completeness. I often jump back on a torrent long enough for all the peers totals to equal a complete copy when it is unseeded so they may share it amongst themselves while I put BW focus on other things.

As far as overhead is concerned a few bits/sec seems trivial and my ratio up/down doesn't seem to suffer as a result.

Think what you will and flame me if you like, but thats just my feelings on the issue.

Posted
when µtorrent 1.4.0 clients are connected to me and are not sending pieces to me to the tune of -3:1 ratio, I kick 'em.

If you're seeding, why would a client send you a piece? Or do you mean HAVE messages? µtorrent sends HAVE messages to downloading peers; it doesn't send them to seeds (to conserve the seed's bandwidth and its own).

Posted

You don't seem to get how BitTorrent works, please refrain from using the kickban function.

Have messages have nothing to do with sending actual piece data.

And a ratio of even 10:1 is quite common with peers. What matters is their overall ratio, which YOU cannot see, unless you have direct access to the tracker stats. And there's also the fact that many people seed afterwards.

Posted
µtorrent sends HAVE messages to downloading peers;

Seems strange that they don't send them to me when I'm part of the unfinished swarm.

In any case it seems pointless to continue this topic, as I do understand how bittorrent works and what I see is what I've posted.

Posted

They do send HAVEs, but not for pieces that -you- sent them. And like I said, have messages have nothing to do with anything at all, it's totally unrelated to any piece data actually sent to you.

Posted
You don't seem to get how BitTorrent works, please refrain from using the kickban function.

:rolleyes:

You may be right in theory but in practice the kick/ban function is a very useful tool for uploaders (especially those on limited bandwidth)

If you know the IP's of (fast) uploaders (usually on smaller trackers of course) you can use them as hubs, kick/ban the rest and have much faster uploads. Or just use Swedish & Japanese high speed lines as hubs (the Azureus counter locator plugin helps here)

That's not theory, but experience ;)

uTorrent 1.4 is really annoying in the sense it doesn't sent back info about it's progress to the seeder. Good thing it's fixed in the beta version.

1.4 is on my Stuffer blocklist just for being irritating* :P

This is not meant to diss uTorrent. I think it's one of the best clients and I like it a lot, it just needs the bt.send_have_to_seed set to "true" by default and a kick/ban feature (yeah I know it will probably not be added).

* note: all other versions are not affected

Posted
it just needs the bt.send_have_to_seed set to "true" by default

And screw low upload speed users over on seed biased environments? Gee, what a nice fellow you are.

I bet if Azureus did the same to help low upload speed users, you wouldn't be so eager to ban peers left and right. :)

Posted

it IS on, on the betas, but it's configurable. So if you see the same "issue", there's no point kickbanning them, they're as legitimate as any other user, they're just saving bandwidth. The haves don't affect anything anyway.

Posted
You might want to, to save bandwidth.

yes, apparently you'll save lots of bandwidth because there are lots of people with TOO MUCH TIME ON THEIR HANDS who will kick/ban you, so nothing to download, nothing to upload, lots of BW saved.

I think some people just don't get the whole BT point. Share, not kick/ban. DUH!

Archived

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

×
×
  • Create New...