Ichpuchtli

Include BitTorrent 6 family.... at least they can handle uTP incoming... How wonderful will be the future! Can't wait... edit: Isn't time for 1.9 - BETA ? (at least?) This last alpha is working so well....

uTP goes thru UDP. UDP packets have distinct transit than TCPIP.SYS, obey self-independent parameters not the same valid to TCP packets. AFD strings "equivalent" to TCP MSS (MSS = MTU - header) are "FastSendDatagramThreshold" and "FastCopyReceiveThreshold". M$ default for XP and VISTA with Fast Ethernet 100Mbits cards, the driver sets these UDP AFD's parameters on 1024 bits as stand in RFC rules. UDP don't obey the same TCPWindowSize as TCP. If your driver is at wrong values, this size of the packet in transit can be very very short. http://technet.microsoft.com/en-us/library/bb726981.aspx http://technet.microsoft.com/en-us/library/cc781532.aspx The number expected of packets per second is easy math, since you know the bandwidth (speed) of the transit and the amount of data transfered. This procedure is already working in ALL versions of uT for pure UDP connections. DHT, PEX realizes on UDP. PeerGuardian doesn't log each packet sent/received via TCP, but UDP.

@ Ciberbeing: Where did you saw these "many" UDP connections? (UDP don't SYN, so maybe you are seeing something unreal) The ONLY way to stop uTP at all is working with 1.8.3 or higher. uTP is a way to bypass ISP traffic-shaping (from/to peers ISP's TOO), so, it's a cool thing.

Does "bt.shutdown_tracker_timeout" and "bt.shutdown_upnp_timeout" works only if bt.graceful_shutdown is true?

Not only bad things should be posted... THIS NEW 15380 JUST ROCKS! For the first time I can get FLAT uTP full speed upload. (one torrent uploading to just one peer with 236ms "ping" latency, bt_transp = 15 & net.calc_over = false, PPPoA 4Mbit/600Kbit) :cool:

Thanks for the 14981. Since uTP is now optimized for "full" MTU of 1500, any directions about tweaking Win AFD's FastSendDatagramThreshold value ? Is default 1024 ok or can be optimized for 1500? http://technet.microsoft.com/en-us/library/bb726981.aspx http://technet.microsoft.com/en-us/library/cc781532.aspx And so, FastCopyReceiveThreshold ? Thanks again. GREAT NEWS, DEP finally!

v1.8.3.14755 XP-SP3, Cable 12M/800K PPPoA, 6 active torrents selected, 02 downloads max, 4 upload slots. Torrents: 80 seeding + 02 downloading. Feedback: 1. When any uTP option are enabled (no matter in/out) speed graph looks like a roller-coaster and memory reaches higher numbers (not huge). 03h test. 2. With TCP only, speed is flat mostly at top speed, and memory is at normal level [0.7 x (uTP usage)]. 04h test. 3. "queue.dont_count_slow" (both) seems broken, "Queued Seed" happens with no-one torrent uploading (~15 torrents with peers, 11 "queued seed" and 4 only-seeding-not-uploading). Noticed with TCP (not 100% sure about uTP, seems the same).

Hi, Greetings! Start getting a bunch of these logged, with the new 1.8.2: [date time] xxx.xxx.xxx.xxx:XXXXX: [XXX x.xx .....]: Got Cancel Unrequested: nnn:nnnnnn->16384 AND [date time] xxx.xxx.xxx.xxx:XXXXX: [XXX x.xx .....]: Got Request while choked: nnn:nnnnnn->16384 Is it normal? What this means? Is bandwidth overhead supposed to increase with these? btw: bt.transp_disposition is set to "0". THANKS FOR BOTH GREAT WINNERS APP & SUPPORT.