QUOTE(kenjixx @ Dec 8 2008, 01:27 AM)
can i do this on utorrent 1.8.1
found the same bt.transp_disposition thingy on 1.8.1 also..
or it only works on 1.9 alpha??
It works as in the transport protocols does change when you do that. But not fully functional or in some case not working at all. It seems like a ready function built-in previously to prep for the current alpha actually.
On this subject of
"Don't kaypoh kaypoh about BT clients" no offense but I find it ridiculous. TM people are actually resourceful tards and by this I meant since day 1 when they adopted this bandwidth management strategy, obviously every single major BT client under the sun are included on that list by that specific throttling equipment manufacturer. They're not complete idiots you know...So it goes without saying that whatever it is that we can google out, they can too and possibly in some cases are a step ahead. This is an ongoing fight that all of us have to deal with but not against each otherlah.
Now about uTP:-
» Click to show Spoiler - click again to hide... «
A comment from BitTorrent on UTP:
Firon posted already about UTP:
******
uTP, the micro transport protocol. This UDP-based reliable transport is designed to minimize latency, but still maximize bandwidth when the latency is not excessive. We use this for communication between peers instead of TCP, if both sides support it. In addition, we use information from this transport, if active, to control the transfer rate of TCP connections. This means uTorrent, when using uTP, should not kill your net connection - even if you do not set any rate limits.
******
Just to re-iterate and offer a few more details (there's some pretty wild press reports popping up):
Firon described uTP completely accurately.
uTP is the result of a couple of years of work to try to make a Bittorrent protocol that works better on the internet.
The switch to uTP is at this point purely experimental, but the design objective (counter to some reports in the press) is actually to offer better congestion control than TCP offers, but maintain the same level of performance (speed).
Better congestion control is good for everyone – for users (VOIP, Gamers etc.) as well as for ISPs.
Same performance is what users have come to expect from their BitTorrent application – unless we can offer the same performance, then people will switch to a different BitTorrent client. (In reality we may be able to offer faster speeds too in many circumstances, but this is a byproduct and not the main objective.)
uTP is our UDP-based implementation of the BitTorrent protocol.
Normally BitTorrent is implemented on top of TCP which is the standard congestion control mechanism for the internet.
It so happens that the congestion control mechanism inside TCP is quite crude and problematic. It only detects congestion on the internet once “packet loss” has occurred – i.e. once the user has lost data and (probably) noticed there is a problem. The problems of TCP are fairly well known in technical circles, but it doesn’t get fixed as TCP is one of those protocols that is implemented in every OS, client and server, on the internet. Co-ordinating a giant upgrade is a very long process.
Because BitTorrent publishes the world’s most popular BitTorrent clients AND because these clients are talking mostly to each other (not to web servers), then we have an opportunity to detect end-to-end congestion and implement a protocol that can detect problems very quickly and throttle back accordingly so that BitTorrent doesn’t slow down the internet connection and Gamers and VOIP users don’t notice any problems. This is our objective.
This is great news for users of the internet and even for ISPs as it should mean that people make far more efficient use of internet bandwidth, but don’t over-use it to destruction. If uTP is successful, then internet congestion due to BitTorrent protocol could become a thing of the past. Of course there are many other applications that use the internet and they may also cause congestion, but we can only control what we do. Having said that, given that some press reports suggest that BitTorrent traffic constitutes half of all traffic on the internet, our technology might have a profound impact. We’re trying to do our bit to be responsible citizens on the internet.
While uTP is for now a proprietary BitTorrent protocol, we are also co-chairing an IETF group to address these issues. Hopefully that will lead to solutions that can be standardized and broadly adopted in due course.
Simon Morris
VP Product Management
BitTorrent, Inc.
That last paragraph in the spoiler where it's bold are the most important. So what we have right now as uTP are actually introductory spec meant to test the waters.
It's not for leeching per se and perceived as a method to properly optimize bandwidth both for users and ISP. I'm seeing actual positive results if you multi task this alpha with browsing and clearly it didn't negatively affect surfing. Of course the client will drop down substantially but now we'll have a far more efficient way for traffic. Even if it's just experimental at this stage, some things have to start somewhere.
Right now for alpha build 13582 and 13583, it's clearly stated that it's not for proper runs but testing only and I HIGHLY recommend that you lot heed the advice.
Especially you hardcore leechers and those running seed boxes. Wanna know why? High CPU spikes, backfiring performance for some settings and double check the generated .log files after an hour's run. Try to run utilities such as ccleaner etc. It'll be a long wipe if you'd set multiple overwrites because it's 80mb+ per log minimum.
UDP based fallbacks are actually implemented 2 versions before already in Vuze Azureus (current beta and full 4.0.0.4 implements this more stable than µT's alpha IMO) and even Halite's current libtorrent 0.14 based snapshot.
P.S good mods:- I think it's a good idea to merge this to µT's thread?