Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!uakari.primate.wisc.edu!hemuli.tik.vtt.fi!fuug!news.funet.fi!sunic!kth.se!ugle.unit.no!nuug!ifi!enag From: enag@ifi.uio.no (Erik Naggum) Newsgroups: comp.protocols.tcp-ip Subject: Re: UDP Reliability between processes on same host Message-ID: Date: 1 Apr 91 20:30:07 GMT References: <1991Mar28.220615.5501@newbridge.com> Sender: enag@ifi.uio.no (Erik Naggum) Organization: Naggum Software, Oslo, Norway Lines: 51 In-Reply-To: todds@newbridge.com's message of 28 Mar 91 22:06:15 GMT In article <1991Mar28.220615.5501@newbridge.com> todds@newbridge.com (Todd Sandor) writes: Please don't flame me, I know UDP is unreliable, but I have a question concerning using UDP between processes on the same host. My experience is that UDP is reliable on the same host, and especially so if you use the loopback (127.0.0.1 on some systems). The problem with assuming that you talk to the same host is that one day, you don't. The extra cost of sequence numbers, timeouts and retransmits (which need only be trivial -- otherwise I would suggest TCP), won't be incurred as long as you talk to your own host. Sure, it's more code, and you need to check that you got the right packet and so on. As message sequence integrity is one of your concerns, I suggest that you use sequence numbers "just in case". It _could_ be that the network code implementation on your system uses a LIFO type buffer for outstanding packets, and that you will find out only under heavy load, as you allude to. - socket overflows or - bad data length fields or - bad checksums I have a hard time thinking up conditions under which you'd get more than the first problem on a local host, but as I said, you could suddenly find yourself having two hosts communicating. Your code should work, regardless. but could we experience out of order packets or duplicate packets. You should make sufficient safety nets to allow for these conditions. Sequence numbers will do. For instance, you could provide a minimal layer which, when expecting n packets, read packets and requested retransmits until it got all of them, then delivered them back to the caller in sequence. Or you could make this layer buffer up packets arriving out of sequence and deliver the "next" (expected) packet when called. (This will require negotiation of initial packet numbers between the communicating processes, and dynamic memory handling, both of which may become costly.) I can't speak on the relative speed of using (one of) the address(es) of the host or using the loopback. Intuitively, one would expect a slightly higher throughput with the loopback, using your reasoning. All I can say is I'm pretty certain that no implementation is slower for the loopback than one of its other addresses. Hope this helps. -- [Erik Naggum] Naggum Software, Oslo, Norway