From mboxrd@z Thu Jan 1 00:00:00 1970 To: 9fans@cse.psu.edu Subject: Re: [9fans] rudp From: Eric Grosse MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Message-Id: <20010908165936.CCAAF199E4@mail.cse.psu.edu> Date: Sat, 8 Sep 2001 12:59:34 -0400 Topicbox-Message-UUID: eb46c4a0-eac9-11e9-9e20-41e7f4b1d025 > From: Sam > Date: Sat, 8 Sep 2001 11:48:10 -0400 (EDT) > > is there any documentation available for the p9 RUDP (snoopy -r)? UDP is simple and fast for local communication, but eventually applications have to come to grips with the fact that it isn't reliable. Perversely, errors never seem to show up in initial testing but as failures in crisis situations. Plan 9's RUDP is a protocol that delivers packets reliably and in order. It is lightweight, without the elaborate congestion avoidance mechanisms of TCP, and is therefore not suitable for wide-area applications. As used in some projects, RUDP is defined as a new IPv4 protocol type (unofficially assigned 254) but it can as well be invoked by an application above unmodified UDP. See the ip(3) man page. Dave Presotto is the author. The basic idea is to add a 32-bit sequence number to packets and to piggyback acknowledgements on replies. Simple flow control is achieved by allowing up to 100 unacknowledged packets. A randomly initialized "generation number" is made part of the header so that packets from different conversations are not confused. If either end reboots (or if ten retransmissions fail), all queued packets are dropped but otherwise the conversation continues. Thus in normal circumstances, there is a small byte overhead but no extra message traffic compared to plain UDP. trivia: * rudp->headers is usually set to headers=6. The headers=4 version was for transition while we still had old codes that assumed IPv4 address lengths. The headers=0 version is suitable for simple point-to-point communication, but UDP applications commonly wind up with multiple clients or multiple servers. * The random drop feature is purely for testing robustness in the face of severe packet loss; you can probably ignore it. Eric