funchords

Devs & Forum Mods/Admins, I just posted a quick message at http://www.dslreports.com/forum/r21526209-Re-Notice-new-uTorrent-Alpha-may-be-able-to-evade-throttling to help some folks who were not getting the performance that they expected. While I think I was accurate, please review it for me and correct any suggestions that I got wrong or add any others you might have. Thanks Robb Topolski (funchords)

event:completed is a dumb way to determine if you are a downloader. The left parameter is a better choice. event:completed is only sent once (if at all). The left parameter is sent on every announce. The specification is vague in this regard. It could be interpreted as 100% of the entire archive without exclusions. It could also be interpreted as 100% of the archive (excepting exclusions). Additionally, the official specification (on bittorrent.org) says that the entire event parameter is optional -- which makes event:completed optional, too. That's accurate. On the other hand, if you are done downloading and are only uploading, you're not quite a leecher. You're an un-person.

I can't find anything about that router. Are you sure you have the model correct? In particular, I'd like to know whether it actually does something to the packets that appears differently on the WAN side (such as tagging it for ClassofService). Many routers implement QoS only up to the gateway, allowing higher-priority packets to "cut-in-line" ahead of lower priority packets ... but once they leave the gateway onto the Internet, they're all treated the same.

So Bitme said "Bite me." Oh boy!

That's just DHT keeping its mesh up, looking for neighbors, and etc.. The DHT query that is made when a non-private torrent is started is "get_peers" (in plaintext) and will include the infohash (in hex, of course). That query will be made to the neighbors (in hundreds of packets). Just by volume alone, it's easy to tell the difference between activity when starting a private torrent vs. activity when starting a public one, but those specific searches will make it easy.

At first, it was because of the > 4GB bug in 1.7, which is fixed in 1.71. Then it was because uTorrent "leaked" information on private torrents. I just got done testing this, and it does not make the DHT "get_peers" query or do anything else out of the ordinary on DHT, when you add or start a private torrent. No information is leaked. Finally, as I was testing the above, a third reason for banning 1.7+ was added: BitTorrent Inc.'s ownership of uTorrent and their deals with Hollywood.

I like Proximo's display idea, using the Ellipsis: "The.Combined.Written.Works.of.Manki...pdf"

Going from memory on the spec -- It is expected that the listing is altered, and required that the trackers within each tier (those entries without intervening spaces) are randomized. I'd have to go read the spec again to be certain, but I think it's that the randomization of the tiers ensures that the start/stop messages are received consistently and the randomization within the tiers ensures that load balancing occurs. If I'm wrong, don't shoot me. But I know I'm close. If it were consistently placing it in alphabetical order, then this would be a problem. It sounds like several people are saying that it is not placing them in alpha order.

I have auto-update for betas turned on ... yet I'm still not getting prompted to update.

Thank you, Lord Alderaan, sounds like a good plan to me.

Firon, thanks. I just tested this with a batch file opening several instances of telnet and you are right about this. Upon opening the X+1 incomplete connection attempt, the SYN is delayed until one of the first X attempts is answered, closed, or times out. This is much worse than I presumed. Furthermore, Microsoft has removed all mention of the actual limits from their website. This generic text (from an SP2 rollout doc file) is pretty much all that remains, and it's probably what I read when I misunderstood: Limited number of simultaneous incomplete outbound TCP connection attempts Detailed description The TCP/IP stack now limits the number of simultaneous incomplete outbound TCP connection attempts. After the limit has been reached, subsequent connection attempts are put in a queue and will be resolved at a fixed rate. Under normal operation, when applications are connecting to available hosts at valid IP addresses, no connection rate-limiting will occur. When it does occur, a new event, with ID 4226, appears in the system's event log. Why is this change important? What threats does it help mitigate? This change helps to limit the speed at which malicious programs, such as viruses and worms, spread to uninfected computers. Malicious programs often attempt to reach uninfected computers by opening simultaneous connections to random IP addresses. Most of these random addresses result in a failed connection, so a burst of such activity on a computer is a signal that it may have been infected by a malicious program. What works differently? This change may cause certain security tools, such as port scanners, to run more slowly. How do I resolve these issues? Stop the application that is responsible for the failing connection attempts.

> As for 1.7 beta - had a strange issue. I only received 1 node, after about 10 minutes, > in DHT when I usually get about 200+. I right clicked and disabled DHT, right clicked > again to enable DHT, and it did the (Login) and numbers starting going up. Another > application start I had no DHT issue. Should be fixed since build 1167, if this is the duplicate ID issue. The behavior is similar > XP SP2, Server 2003 and Vista (besides Home Basic) are capable of 10 half open > connections. 2000, XP and XP SP1 are capable of something like 65,535 half open > connections (anyway, a really high number, at least what I wrote). I won't blame you at all for writing that, because Microsoft did publish that "fact" regarding this feature in SP2 and other OSs. However, that fact is so badly out of real context and is misleading, that it should be considered false. Connections attempts are serial. They would be limited by the datarate of the network card and the speed of your upload connection -- not to mention that you only have about 3800 ephemeral ports that you can use, and limited memory in both Windows and your NAT device. > The thing is that it > should be higher than that, at least 32 or 64. Why should it be higher than that? When you exceed the outgoing half-open rate of X per second, Windows writes a warning in the log and imposes a limit of X per second. Then it merely delays the connection attempt by the amount necessary to stay within the limit -- no Winsock error is returned to the application due to this delay. This delay should only happen when starting a torrent or getting an announce with a large amount of new peers. With everything except Home Basic, even the largest "simultaneous" attempt might incur a delay of only a few seconds. I am concerned about the new limit of 2 per second on Vista Basic and possible impacts on P2P apps generally. Winsock still shouldn't issue an error when 2 per second is exceeded, but if applications have tiny timeouts, outgoing connection attempts in a newly (re-)started large torrent or after a large announce with peers may be timed out by the application before the SYN packet is actually sent by the network stack. It shouldn't cause a fault, failure, or severe error. Anyway, 2 seems rather draconian.

v:1111 (I will upgrade soon) ... BitLord 1.1 is (still) reported as BitComet/0101