[p2p-hackers] UDP file transfer protocol peer review

[Greg Bildson]

> 	It would be interesting to know whether LimeWire and BearShare
> did any experiments in that field - ideally, the long FTP transfer
> should be unaffected by the parallel P2P transfers (which should not
> make any progress in the meantime, of course). Greg, did you try
> measuring something like that?

Serguei,

I just noticed your question now as I read backwards through these emails.

LimeWire's UDP goal was very minimal - make it work without blowing up the
internet.  I don't recall testing it against a steady ftp stream although
that would be an interesting test.  I did test it on a server with heavy
load and it performed fine.  Our goal was not to have zero impact on TCP
connections; we just wanted to coexist reasonably well.

> 	More often than not all these streams are TCP, so if you wish to
> get your mail or do some Web browsing, your new TCP connection becomes
> just another one among 5, 10, or 20 already saturated P2P ones. Hence
> its data transfer rate will be 6, 11, or 21 times slower than what you
> used to have without P2P application running, and your user experience
> will suffer accordingly.

We actually borrowed a trick from BearShare to get around this problem.  We
pause all TCP activity of the client for 1 second every other second (if the
user is not idle I believe).  By pause here, I mean that we stop reading and
writing.  This appears to leave room for other applications (browsers,
email, etc) to do their thing - surprisingly with little effect on
throughput.  Note that during the pause, system buffers could still be
getting filled up and emptied out to some extent at least.  It was fairly
surprising to find out just how well this approach worked.  One caveat was
that this approach worked horribly when applied to UDP file transfers -
likely due to the smaller built in buffering capabilities and quick slow
down when the buffer is close to being full.

Thanks
-greg