Possible Torrent Alternative.
andrew.jorgensen at gmail.com
Wed Oct 24 17:46:11 MDT 2007
On 10/24/07, Lonnie Olson <lists at kittypee.com> wrote:
> The overhead of TCP really isn't that bad. Only 3 packets to start a
> connection. And an extra return packet for each packet sent.
We obviously have very different opinions of what bad overhead is.
> p2p apps wouldn't work very well on top of UDP. UDP has no delivery
> guarantee. Your proposal will increase overhead beyond that of TCP,
> because no you have to re-implement retransmissions and data order.
> Causing even slower downloads.
I'm NOT advocating a UDP P2P protocol but this is just plain wrong.
To put it simply if TCP can do it so can you. TCP has a lot of bulk
in it that you just don't need and there are definitely going to be
better ways you can do things if you write your own transport layer
specific to your application. As long as you don't do a significantly
worse job than the authors of TCP and you're not trying to implement
all of the features of TCP you will not have "slower downloads" than
you would with TCP.
In-order transmission and sliding window, for instance, are not needed
at all for a BT-like protocol, and since the protocol would be largely
stateless there's no need for setup and tear-down. Transport-layer
checksums are also wasteful since the tracker would have described the
proper checksums of the file chunks.
Obviously it wouldn't be trivial to implement a P2P transport but it
is by no means impossible to out-do TCP if you want to. The question
of if it would be worth your while to do so is another entirely.
More information about the PLUG