Possible Torrent Alternative.

Steve smorrey at gmail.com
Wed Oct 24 11:53:18 MDT 2007

TCP is overkill, we need neither guaranteed, nor reliable, nor ordered delivery.
The request for bytes either comes back as a yes here's your bytes, or
no sorry we don't have those bytes but we do have this list of bytes,
or no sorry we don't have any bytes.

The bytes can come in any order, and the application simply re-assembles them.
Therefore UDP would be better in this case IMHO.

I see no reason to incur all the overhead that maintaining a TCP
connection entails.
Also one main purpose of this protocol is to prevent a man in the
middle attack with packet spoofing from occuring.  TCP is susceptible
to this in a unique way since a simple flow control packet, can
shutdown the connection on both sides.

With a signed and encrypted UDP this would not really be possible, or
at least I fail to see how that would be possible.  Although I guess
data poisoning is still possible.


On 10/24/07, Michael L Torrie <torriem at chem.byu.edu> wrote:
> Steve wrote [-1 top post, -1 no trim]:
> > Well,
> >
> > One reason for using UDP, rather than TCP would be the simple fact
> > that TCP has significantly more overhead than UDP.  That overheads
> > costs bytes, by removing that overhead we perform the same function
> > with a fairly good savings on bandwidth.
> Sure but for most things you're going to have to build connections on
> top of that anyway. So in the end you're going to end up with more
> overhead than TCP.  Instead of letting the protocol stack deal with
> corrections, retransmissions, etc, you'll be forced to do that yourself,
> at the application level.  This will cost more bytes in the long run.
> ><snip>
> /*
> PLUG: http://plug.org, #utah on irc.freenode.net
> Unsubscribe: http://plug.org/mailman/options/plug
> Don't fear the penguin.
> */

More information about the PLUG mailing list