uTorrent banned on several trackers!

[SystemsGuy]

1.7.2 is respecting the private flag w/regard to LPD - it's announcing public hashes and not announcing private. This is a big step in the right direction.

That said, it's still not announcing hash_failed pieces as downloaded, which seems to be to be in violation of the spec, but that's a different issue.

Limited testing (~45 minutes of capture) with only a torrent with the private flag set did not result in any traffic exchange between any addresses other than the ones announced by the tracker.

<soapbox>

I still question the use of multicast for LPD, as it provides a very easy way to identify uTorrent clients on a network segment, and any ISP or network administrator can trivially expand the multicast domain to include whatever segments they route for. That sure as heck is a lot easier than having to sniff all your egress traffic looking for a hit on a signature....

</soapbox>

[DreadWingKnight]

Whatever method is used for LPD, it will be easily identified as a torrent client on a network segment.

[Smoovious]

If you don't want LPD enabled... disable it... jeesh...

As for the stats reporting... I agree that downloading should only count valid data... who wants to be on a torrent having tons of bad data being shoved down your throat for a while before hashfail banning kicks in, only to have to make up for that bad data later.

If bad data being included is part of the protocol as some say, then that is more of a problem with the protocol that has been overlooked, than with µT considering bad data, as bad.

-- Smoovious

[system]

So, uT should change the protocol?

This is a core section of the protocol that has not changed in years, it's not some minor extension.

If a client doesn't follow the very basics of the protocol, then it isn't a bittorrent client but something else.

Hell, bitcomet got a major kicking for ignoring the interval flag, and it's allowed in the specs for clients to announce more regularly than the interval flag specifies. What they did was entirely within spec.

[Thehound]

The announce time is within our tracker's specified tolerable range for 1.7.2. I say it's looking good And actually, Bitcomet got the most kicking for stats errors and ignoring the private flag, which is why 1.7.1 remains banned at our tracker. 1.7.2 is allowed.

PS-Nice to see you here system.

Edit: As to Smoovious' comment, he is 100% correct on the stats only reporting good data. Most good clients already do that and now utorrent is following suit. Azureus 2.5.0.4 and rtorrent 0.7.1+ all do the same. Users should not pay on their ratios for swarm polluters I feel. So, it is the right thing to do.

Edit2: To be technically correct, Azureus 2.4.x also discards bad data from the stats. I was using 2.5.0.4 as an example.

[Ultima]

@system:

http://azureus.sourceforge.net/changelog.php?version=2.3.0.6 (released November 22, 2005)

Core | Download totals don't include hash fails and discards and aren't included in share-ratio calculation

Azureus has done this for the longest time now, and apparently, no one's complained. Even if the ratio looks very slightly more favorable for µTorrent ratio-wise with this change, what about how much more favorable it's always looked for people who are actually sharing the hashfailed pieces?

[system]

It got a kicking for all of those things, and more (like hammering peers) :-P

[Smoovious]

So, uT should change the protocol?

It isn't changing the protocol, it is following it.

The only difference, is that Az's, and now µT's interpretation of 'downloaded', differs from yours apparently.

This is a core section of the protocol that has not changed in years, it's not some minor extension.

It hardly qualifies as a 'core' part of the protocol. At best, it is simply logging. Not even close to 'core'.

If a client doesn't follow the very basics of the protocol, then it isn't a bittorrent client but something else.

Not that it is relevant here, but Bram Cohen/BitTorrent Inc, developed the protocol. If anyone can change it, surely the developer of it can.

Hell, bitcomet got a major kicking for ignoring the interval flag, and it's allowed in the specs for clients to announce more regularly than the interval flag specifies. What they did was entirely within spec.

Well, then since it is so compliant, unban it.

Frankly, it seems outrageous that many private tracker admins are going so ape-shit over this bug having been fixed, so the peers can get treated fairly.

Almost like you people are so desperate to keep people seeding, that you'll go after any reason to make sure they have to.

Maybe we should also count all the overhead in the statistics too?

The two leading clients now report the stats fairly, and accurately, and it isn't going to change. Deal with it.

-- Smoovious

[Ultima]

Edit: As to Smoovious' comment, he is 100% correct on the stats only reporting good data. Most good clients already do that and now utorrent is following suit. Azureus 2.5.0.4 and rtorrent 0.7.1+ all do the same. Users should not pay on their ratios for swarm polluters I feel. So, it is the right thing to do.

/me gives Thehound an e-high5 xD

[Firon]

The announce time is within our tracker's specified tolerable range for 1.7.2. I say it's looking good

Speaking of which, one of the things planned for 1.8 is to (finally) restrict update tracker so people don't manually hammer the tracker. It will either use a) a one minute minimum or the minimum interval set by the tracker, if present.

[system]

@Smoovious

Private trackers can ban what they like, deal with it.

Not the best of answers is it?

In case you haven't realised, the spec published at http://bittorrent.org/protocol.html is the core of the protocol. It is the very basics of how a client should work and includes no extensions. Not even compact is listed there.

Uploaded/downloaded/left are core parts of the protocol.

It's also includes very little space for interpretation.

downloaded The total amount downloaded so far, encoded in base ten ascii.

left The number of bytes this peer still has to download, encoded in base ten ascii. Note that this can't be computed from downloaded and the file length since it might be a resume, and there's a chance that some of the downloaded data failed an integrity check and had to be re-downloaded.

So that's the total amount downloaded then, not the total amount minus whatever the client feels like discarding.

It is specifically mentioned that downloaded cannot be used for anything other than counting download because hash fails will throw the figure out of line with any downloaded+left=filesize calculation.

Finally, if bram wants to change the protocol then he would certainly be in a position to do so. The fact that the page linked above has not changed is evidence that there has been no change in protocol.

[DreadWingKnight]

That protocol document does NOT specify that downloaded pieces that failed hash checks need to be included in the value.

You may turn around and say that it doesn't specify that they don't need to be included, but the fact of the matter is that the document is very nonspecific on the topic.

[Smoovious]

@Smoovious

Private trackers can ban what they like, deal with it.

Not the best of answers is it?

Nope... perfectly fine answer... and I'm the wrong person to play that card on. The others care more about the private trackers still allowing µT a hell of a lot more than I do. I believe what I've said the most was along the lines of, (paraphrased) If they wanna keep banning µT simply for having their heads up their asses, let them. The intelligent users of their sites will eventually move to another index being run by a more intelligent admin, leaving behind a userbase they deserve.

In case you haven't realised, the spec published at http://bittorrent.org/protocol.html is the core of the protocol.

You have a very messed up idea of what is considered 'core'. You could rip out every single stats-keeping part of the protocol, including the boolean that indicates to the tracker if the peer is a seed or not, and it wouldn't hurt the function of the protocol one little bit. If it really was a 'core' part of the protocol, it would thoroughly break the protocol to the point of uselessness.

Fact is, that 'downloaded' is now reporting its stats correctly, as the protocol intended. There has been no change to the protocol. You're just talking out of your ass, looking for any piddly little reason you can dream up to trash µT, and its sad.

Uploaded/downloaded/left are core parts of the protocol.

Only in the loosest, unintelligent, and completely wrong, interpretation of the word 'core'

Uploaded... the amount of bytes of the torrent that has been uploaded

Downloaded... the amount of bytes of the torrent that has been downloaded (hashfails, fail, and are not saved or accepted. therefore, that amount of the torrent, hasn't been downloaded)

It's also includes very little space for interpretation.

You are mistaken here too.

So that's the total amount downloaded then, not the total amount minus whatever the client feels like discarding.

It isn't 'whatever the client feels like discarding'. Now enough of this silliness.

It is specifically mentioned that downloaded cannot be used for anything other than counting download because hash fails will throw the figure out of line with any downloaded+left=filesize calculation.

A shortcoming, which has now been fixed.

Finally, if bram wants to change the protocol then he would certainly be in a position to do so. The fact that the page linked above has not changed is evidence that there has been no change in protocol.

No, it isn't. It only means that it hasn't been updated in a while.

And I'll repeat. There has been no change in the protocol. The only thing changed, is that counts which should not have been counted in the first place, are now not counted, as it should be.

Now...

QUIT WHINING!

-- Smoovious

[callous]

@µtorrent-Guest

Has anyone tried to sniff the packets uTorrent sends from a transparent proxy in front of the uTorrent machine, as opposed to from the same machine uTorrent is running from?

What conditions are ppl using when they say they are monitoring the traffic?

[µtorrent-Guest]

callous:

as I said, my point of sniffing is at the router between the box µT is running on and the DSLAM.

Where others "stick their fingers in", I don't know.

[Thehound]

@µtorrent-Guest

Has anyone tried to sniff the packets uTorrent sends from a transparent proxy in front of the uTorrent machine, as opposed to from the same machine uTorrent is running from?

What conditions are ppl using when they say they are monitoring the traffic?

I used the same box but under a very different condition than normal for the sniffing, so I didn't have to rewire my network but any rootkits would be caught that happened to try to avoid sniffing. I had utorrent running on a VMWare guest networked through the host OS. The host OS was running the sniffer. This method has proven effective in the past as the guest OS is not allowed to connect directly to the network interface under this condition and while the guest OS might get tainted by a rootkit, etc the host OS remains isolated and uncorrupted.

I am satisfied the latest build of utorrent is safe until it's time to test the next build.

[Switeck]

Straight from http://bittorrent.org/protocol.html :

"The choking algorithm described below is the currently deployed one. It is very important that all new algorithms work well both in a network consisting entirely of themselves and in a network consisting mostly of this one.

There are several criteria a good choking algorithm should meet."

(My emphasis added to the most important part.)

Definitive proof that not only is the guide a loose one but also that the various BitTorrent clients need to be compatible with one another...even if they do things differently.

[Honeyfrog]

one of the things planned for 1.8 is to (finally) restrict update tracker so people don't manually hammer the tracker. It will either use a) a one minute minimum or the minimum interval set by the tracker, if present.

I sure would NOT like option "b" at all, since a lot of long-lived "old, reliable shoe" trackers scrape only every 30 or 60 minutes (which was probably prudent back when computers were slugs and people used modems, but is a joke today). One minute, or even five, is reasonable. When I'm initially-seeding, I usually have to hit the Update command a couple times in the first hour to goose peers into showing up.

[DreadWingKnight]

Honeyfrog, I have banned clients that automatically announce every 5 minutes.

Enforcing the limit set by the tracker is prudent in that situation.

Allowing people to announce more often than the minimum interval set by the tracker is allowing users to DoS the tracker.

[Lord Alderaan]

The reason it can be left to the tracker is because the tracker is the one that has to handle and pay for the traffic. If you have 30.000 users updating every minute that could cause quite some traffic. Traffic that might make keeping ur tracker running more expensive (faster machines, faster connection, more GB bandwidth each month) then you want.

This way a tracker has some degree of control over the bandwidth usage. I've been a supporter of b for a long time and I don't even run a tracker. Although more then 30 minutes is indeed a bit on the high side and maybe µtorrent should implement a maximum of 30 minutes to the minimum. Might be a good thing to keep trackers from doing weird things.

[djGrrr]

Actually, it has pretty much nothing to do with traffic use at all, considering a tracker with avg 68000 peers with 25 mins announce interval only uses 1GB traffic a day, its actually completely to do with how much cpu power it requires

[idezmax]

thanks.

-----------------------

http://www.idezmax.com

[Lord Alderaan]

Correct me if I'm wrong but a 1 min announce interval would be 25GB a day.

[orcun]

Refering to this post from Ultima

http://forum.utorrent.com/viewtopic.php?pid=264441#p264441

about the 2.3.0.6 changelog of Azureus and the point

"Core | Download totals don't include hash fails and discards and aren't included in share-ratio calculation"

I have checked this with one of the Azureus developers and he stated: This refers to the client *internal* stat calculation *only*.

Azureus does still report all downloaded data regardless of discarded or failed hash check to the tracker.

Might be worth checking it out.

[amc1]

I have checked this with one of the Azureus developers and he stated: This refers to the client *internal* stat calculation *only*.

Azureus does still report all downloaded data regardless of discarded or failed hash check to the tracker.

Which developer, given that I've already spoken to the developer who wrote the code and confirmed that it does report it to the tracker? I'll even point you to the code where it takes places, if needs be.