9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
* Re: [9fans] rudp
@ 2001-09-08 16:59 ` Eric Grosse
  2001-09-10  1:33   ` Scott Schwartz
  2001-09-10 18:58   ` Boyd Roberts
  0 siblings, 2 replies; 10+ messages in thread
From: Eric Grosse @ 2001-09-08 16:59 UTC (permalink / raw)
  To: 9fans

> 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


^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [9fans] rudp
  2001-09-08 16:59 ` [9fans] rudp Eric Grosse
@ 2001-09-10  1:33   ` Scott Schwartz
  2001-09-10 18:58   ` Boyd Roberts
  1 sibling, 0 replies; 10+ messages in thread
From: Scott Schwartz @ 2001-09-10  1:33 UTC (permalink / raw)
  To: 9fans

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



^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [9fans] rudp
  2001-09-08 16:59 ` [9fans] rudp Eric Grosse
  2001-09-10  1:33   ` Scott Schwartz
@ 2001-09-10 18:58   ` Boyd Roberts
  1 sibling, 0 replies; 10+ messages in thread
From: Boyd Roberts @ 2001-09-10 18:58 UTC (permalink / raw)
  To: 9fans

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




^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [9fans] rudp
@ 2002-04-15 16:55 andrey mirtchovski
  0 siblings, 0 replies; 10+ messages in thread
From: andrey mirtchovski @ 2002-04-15 16:55 UTC (permalink / raw)
  To: 9fans


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

indeed. silly me...



^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [9fans] rudp
@ 2002-04-15 15:31 rog
  0 siblings, 0 replies; 10+ messages in thread
From: rog @ 2002-04-15 15:31 UTC (permalink / raw)
  To: 9fans

>			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) {



^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [9fans] rudp
@ 2002-04-15 15:21 Russ Cox
  0 siblings, 0 replies; 10+ messages in thread
From: Russ Cox @ 2002-04-15 15:21 UTC (permalink / raw)
  To: 9fans

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

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



^ permalink raw reply	[flat|nested] 10+ messages in thread

* [9fans] rudp
@ 2002-04-15 14:58 andrey mirtchovski
  0 siblings, 0 replies; 10+ messages in thread
From: andrey mirtchovski @ 2002-04-15 14:58 UTC (permalink / raw)
  To: 9fans

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);
	}
}



^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [9fans] rudp
@ 2001-09-10  1:46 presotto
  0 siblings, 0 replies; 10+ messages in thread
From: presotto @ 2001-09-10  1:46 UTC (permalink / raw)
  To: 9fans

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.


^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [9fans] rudp
@ 2001-09-08 17:52 bwc
  0 siblings, 0 replies; 10+ messages in thread
From: bwc @ 2001-09-08 17:52 UTC (permalink / raw)
  To: 9fans

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

^ permalink raw reply	[flat|nested] 10+ messages in thread

* [9fans] rudp
@ 2001-09-08 15:48 Sam
  0 siblings, 0 replies; 10+ messages in thread
From: Sam @ 2001-09-08 15:48 UTC (permalink / raw)
  To: 9fans

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

sam



^ permalink raw reply	[flat|nested] 10+ messages in thread

end of thread, other threads:[~2002-04-15 16:55 UTC | newest]

Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
     [not found] <ehg@research.bell-labs.com>
2001-09-08 16:59 ` [9fans] rudp Eric Grosse
2001-09-10  1:33   ` Scott Schwartz
2001-09-10 18:58   ` Boyd Roberts
2002-04-15 16:55 andrey mirtchovski
  -- strict thread matches above, loose matches on Subject: below --
2002-04-15 15:31 rog
2002-04-15 15:21 Russ Cox
2002-04-15 14:58 andrey mirtchovski
2001-09-10  1:46 presotto
2001-09-08 17:52 bwc
2001-09-08 15:48 Sam

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).