On 10/24/07, Lonnie Olson <[EMAIL PROTECTED]> 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. - Andrew /* PLUG: http://plug.org, #utah on irc.freenode.net Unsubscribe: http://plug.org/mailman/options/plug Don't fear the penguin. */
