john@anasaz.UUCP (John Moore) (12/14/89)
Just a question... How reliable or unreliable is UDP. I understand that it does not guarantee delivery or sequencing of messages. However, I would like to know how, in practice, it can lose messages, and how frequently it really will do this. Question applies to both Ethernet LAN's, and such LAN's connected via Bridge over lower speed lines. Thanks in advance. -- John Moore (NJ7E) mcdphx!anasaz!john asuvax!anasaz!john (602) 861-7607 (day or eve) long palladium, short petroleum 7525 Clearwater Pkwy, Scottsdale, AZ 85253 The 2nd amendment is about military weapons, NOT JUST hunting weapons!
freedman@euclid.math.temple.edu (Avi Freedman) (12/14/89)
In my experience with UDP staying on one side of a DEC bridge and going between a Sun 4/280 and 5 Sun 3/60s, I lost roughly one out of 10,000 UDP packets. However, this is not at full Ethernet load- I think that the load will be a _major_ factor in how many UDP packets get lost. Also, a slow machine (or a fast machine with a slow ethernet card) may lose packets, and if you're going through gateways/bridges/routers/whatever, they could hiccup or slow down or experience high network loads and lose packets. You get the idea. For applications like the one I was working on (simulating data collection of massive quantities of data points and computing statistics about them), it was not critical if a packet or two got lost, since the entire message was always contained in one UDP packet. Of course, for other applications, where order is dependant or duplication would be unacceptable (implementing a database that sits on the network, for example), I just use TCP. Sorry to be so vague, but UDP packet-loss depends on many factors. If you'd like, I'll send you code to determine how many UDP packets are lost... Avi Freedman freedman@euclid.math.temple.edu
PETEHIC@UOTTAWA.BITNET (Pete Hickey) (12/14/89)
How unreliable is UDP? How fast is fast. Unreliable does
not mean that its not good to use, it just means that you send
out a packet. Thats all you know. If the other machine is alive
and gets it, it got there. If the other machine isn't running/
listening/too busy/etc. It won't get it. The point is that
when you send it, you do not know if it has been received.
The reliability of a UDP packet is about as reliable as a single
TCP packet. At least when its a UDP packet to a single machine.
How reliable is a UDP broadcast?????
=======================================================================
Pete Hickey | Convention says that something funny
University of Ottawa | goes here. Its blank because I have
Ottawa, Ontario, CANADA | funny to say.
(613) 564-7646 |_____________________________________
petehic@uotacdvm.uottawa.CA PETEHIC@UOTTAWA.BITNETamanda@mermaid.intercon.com (Amanda Walker) (12/14/89)
In article <1039@anasaz.UUCP>, john@anasaz.UUCP (John Moore) writes: > [about UDP] > I would like to know how, in practice, it can lose messages, and how > frequently it really will do this. Question applies to both Ethernet > LAN's, and such LAN's connected via Bridge over lower speed lines. This depends almost entirely upon the physical configuration of the network in question. On a single lightly loaded Ethernet, UDP is pretty reliable. The more gateways you have to go through, especially when low-speed links are involved, the higher the chances that your datagrams will be dropped, either because of accumulated errors or simply insufficient buffering in one of the gateways. UDP is most useful as a cheap way to get packets around a local network when retransmission is either unnecessary or easy to figure out how to do. For any application that needs to work over arbitrary distances or needs confirmation that the data actually got to the other end, TCP is probably the way to go. Amanda Walker InterCon Systems Corporation --
sra@lcs.mit.edu (Rob Austein) (12/15/89)
Date: 14 Dec 89 15:08:55 GMT From: amanda@mermaid.intercon.com (Amanda Walker) ... UDP is most useful as a cheap way to get packets around a local network when retransmission is either unnecessary or easy to figure out how to do. For any application that needs to work over arbitrary distances or needs confirmation that the data actually got to the other end, TCP is probably the way to go. This is of course a good general rule, but there is at least one important special case where UDP is (arguably) the right sollution for a protocol that works over arbitrary distances: a configuration with a huge number of clients asking short, infrequent questions of a few global servers. For example, the Domain Name System, where every host on the internet needs to check with one of the half dozen root servers once a week (assuming everybody is implementing the protocol correctly and no machine ever needs to be rebooted or has its cache flushed...). In this kind of configuration, the connection setup involved in using TCP is quite expensive: the shortest likely TCP exchange would require two packets in each direction, and the additional overhead for setting up the TCB on the server might add significantly to the query processing cost. --Rob Austein
amanda@mermaid.intercon.com (Amanda Walker) (12/16/89)
In article <8912141305.aa00864@mintaka.lcs.mit.edu>, sra@lcs.mit.edu (Rob Austein) writes: > This is of course a good general rule, but there is at least one > important special case where UDP is (arguably) the right sollution for > a protocol that works over arbitrary distances: [DNS] Actually, I think of this as a case where retransmission is simple to figure out. For an isolated query/response (such as DNS), UDP is often quite appropriate, for exactly the reasons Rob mentioned. Amanda Walker InterCon Systems Corporation --