Re: [9fans] rudp

Re: [9fans] rudp

[Eric Grosse]

> From: Sam <sah@softcardsystems.com>
> 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

Re: [9fans] rudp

[Scott Schwartz]

| 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.

How does it compare to IL?

Re: [9fans] rudp

[Boyd Roberts]

bsd systems had a #define SOCK_RDGRAM ... but it was never implemented.

Re: [9fans] rudp

[andrey mirtchovski]

> shouldn't this be:
>
> 	if((fd = dial(netmkaddr(host, proto, port), 0, 0, 0)) < 0) {

indeed. silly me...

Re: [9fans] rudp

[rog]

>			if((fd = dial(netmkaddr(proto, host, port), 0, 0, 0)) < 0) {

shouldn't this be:

	if((fd = dial(netmkaddr(host, proto, port), 0, 0, 0)) < 0) {

Re: [9fans] rudp

[Russ Cox]

			if((fd = dial(netmkaddr(proto, host, port), 0, 0, 0)) < 0) {

for starters, change this to host, proto, port.

[9fans] rudp

[andrey mirtchovski]

Hi,

I'm trying to use rudp for testing purpouses around here, but I'm a
tad puzzled by the semantics.  All I want to do is fork once and have
one process connect and send a string (or many) to another using the
rudp protocol.

Ip(3) says that listen is not an option, so the only thing I do is
announce() on one side and connect() on the other.  Unfortunately it
doesn't seem to connect at all.  I looked at
/sys/src/cmd/ndb/dnudpserver.c but I think there should be a simpler
way of doing things...

Error reported on connect is:
can't connect: file does not exist(/net/MACHINE/clone)

where MACHINE is the host i'm connecting to (localhost)...

What am I doing wrong and where should I look for more documentation?

Thanx, Andrey

Oh, yes, obligatory code paste: this is how I'm trying to connect.


char *proto = "rudp";
char *port = "5557";
char *host = "ps1";
char adir[40];
char str[40] = "this is a test\n";
char data[8192];

void main() {
	int fd, fd2;


	switch (fork()) {
		case 0:
			sleep(5000);
			if((fd = dial(netmkaddr(proto, host, port), 0, 0, 0)) < 0) {
				perror("can't connect");
				exits("connect");
			}
			write(fd, str, strlen(str));
			exits(0);

		default:
			if((fd2 = announce(netmkaddr("*", proto, port), adir)) < 0) {
				perror("can't announce");
				exits("announce");
			}
			while(read(fd2, data, 8192) > 0)
				print("parent: %s\n", data);

			exits(0);
	}
}

Re: [9fans] rudp

[presotto]

An rudp channel really is a datagram channel.  Packets are
separately addressed by the user program so that one fd
can be used to maintain conversations with multiple other
end points.  IL is one to one.

IL does have flow control, Rudp doesn't.

Rudp has no keep alive, IL does.

IL does some small amount of congestion control by measuring the
bandwidth delay product of the connection, Rudp doesn't care.

Rudp connections don't hangup when one of the sides reboots, it
just flushes any undelievered messages to that side (and the side(s)
that stays up can know that there was a restart by looking at the error
file).

We used rudp as the protocol between things like controllers
and devices that they control.  For example, between a switch
and a switch controller in a telephony product.

Rudp is just udp with a some extra bytes.  It was originally
done as an option on udp and we later just made it a
separate protocol.  It's protocol number is not registered
witn IANA.

Re: [9fans] rudp

[bwc]

[-- Attachment #1: Type: text/plain, Size: 21 bytes --]

Not that I know of.

[-- Attachment #2: Type: message/rfc822, Size: 1361 bytes --]

From: Sam <sah@softcardsystems.com>
To: <9fans@cse.psu.edu>
Subject: [9fans] rudp
Date: Sat, 8 Sep 2001 11:48:10 -0400 (EDT)
Message-ID: <Pine.LNX.4.30.0109081146110.2754-100000@athena>

is there any documentation available for the p9 RUDP (snoopy -r)?

sam

[9fans] rudp

[Sam]

is there any documentation available for the p9 RUDP (snoopy -r)?

sam