[p2p-hackers] Hard question....

David Barrett dbarrett at quinthar.com
Sat Apr 1 23:24:29 UTC 2006


I entirely agree with Daniel and Matthew here.  TCP does an amazingly good
job on this.  I've abstracted the TCP algorithm into a simple class here:

	http://svn.iglance.com/svn/trunk/iglance/client/GTCP.h
	http://svn.iglance.com/svn/trunk/iglance/client/GTCP.cpp

Basically, use GTCPServer to regulate the send speed and process
acknowledgements, and GTCPClient to construct and maintain the bit-vector
sent back with acknowledgements.  It's not "real" TCP for a wide range of
reasons, but it might give you a start on constructing your own UDP
congestion-control mechanism. 

-david


> -----Original Message-----
> From: p2p-hackers-bounces at zgp.org [mailto:p2p-hackers-bounces at zgp.org] On
> Behalf Of Daniel Stutzbach
> Sent: Saturday, April 01, 2006 2:04 PM
> To: Peer-to-peer development.
> Subject: Re: [p2p-hackers] Hard question....
> 
> On Sat, Apr 01, 2006 at 01:33:18PM -0800, Lemon Obrien wrote:
> > udp you know you'll need to do error correction if a packet is
> > missing; i do this by sending a 're-send' message; but, as some of
> > you know...you can not flod the network with thousands of
> > resends...especially if you relay messages to the destination
> > node...so, my question is; what is a good average mean time to keep
> > sending 're-sends'...i have it working with 500 milli-seconds and
> > 1000...i want fast?
> 
> This is a complex topic and TCP does a lot behind the scenes to get it
> right.  You need a dynamic mechanism to balance:
>  - Sending packets as quickly as possible
>  - But not so fast that they cause congestion and heavy packet loss
> 
> Rather than starting from scratch, I recommend studying the
> way TCP handles this problem.  Here are some good references:
> 
> Van Jacobson, "Congestion Avoidance and Control", SIGCOMM, 1988
> http://ee.lbl.gov/papers/congavoid.pdf
> 
> ^-- Van Jacobson encountered the problem you describe in the original
> implementation of BSD's TCP and fixed it.
> 
> RFC 3782: The NewReno Modification to TCP's Fast Recovery Algorithm
> http://www.faqs.org/rfcs/rfc3782.html
> 
> ^-- Other researchers make a small tweak giving a significant
> performance boost
> 
> W. Richard Stevens, TCP IP Illustrated, Volumes 1 and 2.
> 
> ^-- Volume 2 walks through the BSD TCP source code and explains how it
> all works.
> 
> The SACK extension to TCP may also be useful (especially if your
> application does not need in-order delivery), but it's best to get
> everything else working first before you worry too much about that.
> 
> --
> Daniel Stutzbach                           Computer Science Ph.D Student
> http://www.barsoom.org/~agthorr                     University of Oregon
> _______________________________________________
> p2p-hackers mailing list
> p2p-hackers at zgp.org
> http://zgp.org/mailman/listinfo/p2p-hackers
> _______________________________________________
> Here is a web page listing P2P Conferences:
> http://www.neurogrid.net/twiki/bin/view/Main/PeerToPeerConferences




More information about the P2p-hackers mailing list