Simon Morris
Posted October 8, 2009 at 5:52 pm
As a matter of fact µTP is indeed a replacement for TCP, so we think the name is appropriate. You can check out standardization work which we’re chairing at the IETF called the LEDBAT working group
"Framing is not on the WG's charter."
http://www.ietf.org/mail-archive/web/ledbat/current/msg00117...
If they have special BitTorrent client to BitTorrent client information, it could be for use in their custom software that companies would use within their own product, not necessarily for public downloading usage (ex: WoW's software updates using BitTorrent).
I don't know if this is actually the case. But why couldn't it be a possibility?
They're not even going to pretend other client will be able to support it in a timely fashion. Backwards compatibility is out the window if they really did implement everything documented in the article.
"source code for BitTorrent 6.0 ... will not be released"
http://www.slyck.com/story1566_BitTorrent_Addresses_Closed_S...
I wouldn't expect 7.0 to be any different.
I don't think the article documents any details. Maybe I missed a link.
So my question is, why wouldn't you get the same effect by running BT on top of a network stack using Vegas?
Someone flash the tptacek signal!
If you assume that your own uplink is the only bottleneck to be dealt with (say you are serving torrents over a DSL line) then this is reasonable, but I don't think I'd want to yield to all TCP users everywhere with all of my outgoing traffic.
There are also some scary comments in the notes from before it was rolled into the kernel, like the code doesn't handle route changes.
I can see why a vendor would choose something over which they have control.
You probably would, but Windows doesn't support Vegas.
http://www.ietf.org/mail-archive/web/p2pi/current/msg00052.h...
