Possible Torrent Alternative.

Steve smorrey at gmail.com
Wed Oct 24 11:29:51 MDT 2007


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.

Per packet signing is the only way I can think of to guarantee
authenticity of the packet, if there is a better way, I'm open to
suggestions.

As for the scalability concerns, I don't really see how there would be
a scalability issue here.
Could you please elaborate further?

Also remember you loose the need for a tracker or a torrent file,
which means that the file once loosed upon this network would always
survive as long as one copy exists somewhere, even if that copy if
broken up into constituent bytes and spread across the internet.

It would appear to have great survivablity.

Sincerely,
Steve


On 10/24/07, Nicholas Leippe <nick at leippe.com> wrote:
> > Also instead of a tracker which can be taken down, I propose a query
> > request method using a globally unique identifier,  based on some sort
> > of file signature algorithm.  So essentially you query a list of known
> > hosts for each file, if they don't have it they query all the hosts
> > they know about etc and so forth.  A query result should return a list
> > of known hosts which have the file.
>
> Why you have identified a shortcoming of bittorrent, and the idea of adding
> authenticity at the packet level is a good idea, imo the idea presented here
> to replace the tracker feels reminiscent of having the same scalability
> problems as gnutella.
>
> I don't think a 'simple' solution is often a good solution to a difficult
> problem such as this.
>
> The difficulty of the problem is the reason there have been so many attempted
> solutions already, and why they all have shortcomings.
>
>
> /*
> 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