todds@newbridge.com (Todd Sandor) (03/29/91)
Please don't flame me, I know UDP is unreliable, but I have a question concerning using UDP between processes on the same host. We are using Sun Sparcstations runing 4.1.1 and using UDP sockets to talk between processes on the same machine. I realize UDP is defined as being unreliable, and that we may possibly experience: - socket overflows or - bad data length fields or - bad checksums but could we experience out of order packets or duplicate packets. For example, one the same host, process A and B are up and are bound to each other, process A sends 5 datagrams to process B, will process B get these 5 messages and only these 5 messages in the order that process A sent them? I don't have access to source, so I can`t check this out, hopefully someone can tell me the answer. This is the simple case, (this works as I've tested it), but under extremely HIGH loads, would we run into problems? Also, would it make a difference if the host address we used in bind() call was the "localhost" (address 127.0.0.1 from /etc/hosts file, its the loopback device). Theoretically using this as the host would be faster, I think?, since it wouldn't have go through the routing code in the kernel. Can anyone give me any input to this, is it a good thing to do? How much faster would it be? And finally, can anyone give me input into the robustness of TLI under SunOS 4.1.1. In the manuals it says that sockets are sort of being phased out, was wondering if anyone has any real experience using TLI? /todds -- Todd Sandor Voice: (613) 591-3600 ext 1011 P.O. Box 13600 Newbridge Networks FAX: (613) 591-3680 600 March Road Mail: todds@newbridge.com Ottawa, Ontario,Canada K1G 3Z4
carlson@mrx.webo.dg.com (James Carlson) (04/02/91)
Sure ... they can end up out of order -- UDP doesn't guarantee delivery, and packets may arrive out of order or duplicated. (Of course, this shouldn't happen on the *same* host, but .... !) May I ask why you're not just using IPCs, since that's what it sounds like you need? UDP is usually used for self-contained data (like in XDMCP) and as the basis for a more complex protocol (like TFTP). -- Disclaimer: My company neither knows nor cares what I say. .//.
enag@ifi.uio.no (Erik Naggum) (04/02/91)
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] <enag@ifi.uio.no>
Naggum Software, Oslo, Norway <erik@naggum.uu.no>enag@IFI.UIO.NO (Erik Naggum, the Internet Purist) (04/02/91)
In message <1991Mar28.220615.5501@newbridge.com>, Todd Sandor writes:
... 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] <enag@ifi.uio.no>
Naggum Software, Oslo, Norway <erik@naggum.uu.no>jbvb@FTP.COM (James B. Van Bokkelen) (04/02/91)
...but could we experience out of order packets or duplicate packets? Taking an unsophisticated view, one wouldn't expect out of order or duplicate packets unless IP routers and long-haul paths were involved. However, consider what happens if a packet is lost due to hardware error on your local cable (this WILL happen - believe me): You have to have some sort of mechanism for detecting that it was lost and retransmitting it. If the product of the probability of packet loss times the number of packets outstanding (unacknowleged) at any given time gets high enough, your receiver will see both out of order and duplication. Better to use TCP, IMHO. James B. VanBokkelen 26 Princess St., Wakefield, MA 01880 FTP Software Inc. voice: (617) 246-0900 fax: (617) 246-0901