pclark@SRC.Honeywell.COM (Peter Clark) (07/16/90)
Quick question: Under what conditions would a programmer want to use a UDP connection over a TCP connection? What does UDP give you that TCP doesn't, that makes it worth losing (or implementing yourself) a reliable, guaranteed delivery layer? Pete Clark Honeywell SRC Minneapolis MN
hedrick@athos.rutgers.edu (Charles Hedrick) (07/17/90)
People tend to use UDP where (1) they plan to be making isolated queries, such that the overhead packets used to set up and close a connection would form most of the traffic (2) they need more performance than they think they can get from TCP. The domain system is an example of the first category. You send a one-packet query and get back a one-packet response. If you don't get a response, just try again. NFS is an example of the second category. The folks at Sun apparently believed that they couldn't get good enough performance out of TCP to use it for swapping. In most cases I recommend using TCP. If you use UDP, you end up having to build retransmission algorithms into your application. In most cases you'll get better performance by using TCP, whose algorithms have been well tuned (at least if you are using a recent Berkeley TCP), rather than rolling your own.
rpw3@rigden.wpd.sgi.com (Rob Warnock) (07/17/90)
In answering a beginner's question, hedrick@athos.rutgers.edu (Charles Hedrick) writes: +--------------- | People tend to use UDP where (1) they plan to be making isolated | queries, such that the overhead packets used to set up and close a | connection would form most of the traffic (2) they need more | performance than they think they can get from TCP.... +--------------- I would add: ...(3) there are a very large number of clients accessing a single server, such that the cost of holding a connection open for each active client would be excessive. [The definition of "excessive" is system- and application-dependent.] In some sense this is the same as Hedrick's #1, except that #1 refers to conserving dynamic network bandwidth, and #3 to conserving quasi- static server system resources "wired-down" by connections (sockets, open-file slots, processes, etc.). -Rob ----- Rob Warnock, MS-9U/510 rpw3@sgi.com rpw3@pei.com Silicon Graphics, Inc. (415)335-1673 Protocol Engines, Inc. 2011 N. Shoreline Blvd. Mountain View, CA 94039-7311
murthy@la.excelan.com (M.D. Srinivas Murthy) (07/18/90)
One important reason to use UDP is when broadcasting is needed. You cannot send a broadcast packet with TCP. (One example: rwho) Further if an application is designed as a state-less machine (like NFS) one has to use UDP. -murthy
wunder@HP-SES.SDE.HP.COM (Walter Underwood) (07/18/90)
Hedrick's and Warnock's explanations are interesting, but I sent Pete a rather different explanation for UDP's existance. UDP is for protocols that don't want or need byte streams. It is for protocols that need pure datagrams, often for request/response, and it is for building custom protocols, like NTP. TIME and DAYTIME are the classic request/response examples -- if the reply is lost, TCP would retransmit the old timestamp after a timeout, but with UDP, the requestor times out, asks again, and gets a new timestamp. A transaction protocol that supports idempotent requests would satisfy a lot of the current users of UDP, but it would not obsolete UDP. wunder
henry@zoo.toronto.edu (Henry Spencer) (07/18/90)
In article <Jul.16.21.14.16.1990.26321@athos.rutgers.edu> hedrick@athos.rutgers.edu (Charles Hedrick) writes: >People tend to use UDP where (1) they plan to be making isolated >queries... (2) they need more >performance than they think they can get from TCP... Doesn't it also get some use for things like packet voice, where timely unreliable delivery is better than unpredictably-delayed reliable delivery? Agreed that the basic answer is "use TCP unless you have a very good reason for UDP". If nothing else, it's much easier to get a high-quality implementation by using a pre-built one than by building it yourself. -- NFS: all the nice semantics of MSDOS, | Henry Spencer at U of Toronto Zoology and its performance and security too. | henry@zoo.toronto.edu utzoo!henry
root@asylum.sf.ca.us (Super user) (07/19/90)
UDP has a lot less overhead than TCP. For simple transaction-based protocols (request-response) that don't carry much data, UDP is much simpler to use. TCP would have the additional overhead of setting up and tearing down its connection, whereas UDP sends the request and response and doesn't care about the ret. In request-response protocols based on UDP, you have to worry about three main things: what happens if a packet gets lost (solution: set a timer and retransmit), what happens if you resend the request and its action gets duplicated (solution: be careful about your protocol design, or put sequence numbers in the packets), and what happens if your data doesn't all fit in one packet (solution: IP fragmentation, or split it across packets, or you lose). Splitting data across UDP packets is often a good reason to start using TCP, since it already has a lot of mechanism in it for dealing with this issue. Not many applications use UDP for transferring lots of data. Those applications are normally TCP-based. However, UDP is very convenient for applications wishing to use a bulk data transport protocol with different behaviour from TCP. This kind of work would be mostly experimental, though. SNMP, the main network management protocol for the Internet, is layered on top of UDP. One advantage to this is that it allows those vendors that might provide SNMP in their products that would otherwise have no (IP) protocol stack (like an ethernet hub) to include SNMP without having to implement a full TCP. While getting a TCP implementation running today is easier than it was several years ago, UDP is orders of magnitude simpler. - john romkey USENET/UUCP: romkey@asylum.sf.ca.us Internet: romkey@ftp.com "There is no loyalty except loyalty to the party. There is no love except love of Big Brother. All competing pleasures we will destroy." - 1984 (film)
ejp@icd.ab.com (Ed Prochak) (07/20/90)
In article <64291@sgi.sgi.com>, rpw3@rigden.wpd.sgi.com (Rob Warnock) writes: > In answering a beginner's question, hedrick@athos.rutgers.edu > (Charles Hedrick) writes: > +--------------- > | People tend to use UDP where (1) they plan to be making isolated > | queries, such that the overhead packets used to set up and close a > | connection would form most of the traffic (2) they need more > | performance than they think they can get from TCP.... > +--------------- > > I would add: > ...(3) there are a very large number of clients accessing a single > server, such that the cost of holding a connection open for each > active client would be excessive. [The definition of "excessive" > is system- and application-dependent.] > > In some sense this is the same as Hedrick's #1, except that #1 refers > to conserving dynamic network bandwidth, and #3 to conserving quasi- > static server system resources "wired-down" by connections (sockets, > open-file slots, processes, etc.). I think Rob's condition is important in some cases. (at least that and the following was the justification I used for an application using UDP). In addition: ...(4) preservation of record boundaries. TCP provides the data to the reciever as it is available. This means messages may be fragmented and it is up to the application to parse out record boundaries. There are some applications that prefer to receive messages intact, making UDP the protocol of choice, in this case. As usual, the case is one of no single right answer. It all depends on the situation. (I hope someone summaries this thread.) ed Edward J. Prochak Voice: work-(216)646-4663 home-(216)349-1821 Email: {cwjcc,pyramid,decvax,uunet}!ejp@icd.ab.com USmail: Allen-Bradley, 747 Alpha Drive, Highland Heights,OH 44143 As defined by a civil engineer named Wellington, ENGINEERING is "the ability to do for one dollar, what any damn fool can do for two."
bzs@world.std.com (Barry Shein) (07/21/90)
>Quick question: > Under what conditions would a programmer want to use a UDP connection > over a TCP connection? What does UDP give you that TCP doesn't, that > makes it worth losing (or implementing yourself) a reliable, > guaranteed delivery layer? > > Pete Clark I assume you mean UDP over IP, not over TCP, otherwise it's not a quick question, it's a strange question and needs some clarification. Consider the following situations: 1. I have designed an application which embeds ECC integers and sequencing into its packets. It's mostly a one-way protocol (on request blasts a lot of data), so asynchrony is not particularly useful. The ECC allows the remote end to detect and correct one or two bit errors without resend. I have determined (?) that 99.99% of all errors are one or two bit (of course, sequence errors might require entire resends, but I can handle that.) Why would I want TCP to also check every packet and silently resend when most of the time I can correct without resend? 2. I am sending an animation which consists of 1Kx1Kx8 bit frames over the network. I do some rudimentary checking (sequencing etc.) but, more importantly, need to (usually) keep up with 30-frames/second. A few bits in error might mean the image on the screen is "smudged" in some tiny area for 1/30th of a second (this assumes a network connection with few errors, tho not zero errors.) Is it worth waiting and having TCP resend those packets? Or just let the screen update on the next 30th of a second which will probably fix the image (that is, would anyone notice a few small xmit errors?) 3. I am blasting data similarly to (2) over ethernet. Ethernet hardware does a CRC on the data although, again, doesn't guarantee sequencing (packets might be lost entirely, but if they get there they're correct.) 4. Finally, UDP/IP can be implemented on a machine with raw access to a network device in a (longish) afternoon. I've done it (the 3B2/HP UDP/IP/TFTP source that floats around was written by me from scratch and put into production over a weekend.) There is value in getting a few bits across as a bootstrap. Caveat: It is a fallacy that because UDP is much simpler and lower overhead that it is therefore inherently faster. For example, the lockstep protocol of TFTP/UDP is usually much, much slower (an order of magnitude) than a decent FTP/TCP. Asynchrony is much more important than mere CPU cycles. Ask the right questions! (note that in the examples above I haven't excluded asynchrony.) -Barry Shein Software Tool & Die | {xylogics,uunet}!world!bzs | bzs@world.std.com Purveyors to the Trade | Voice: 617-739-0202 | Login: 617-739-WRLD
jbvb@VAX.FTP.COM (James B. Van Bokkelen) (07/23/90)
One point I would add, Barry: You (or another ranking net.guru) would be quite capable of recognizing a special case of the sort you posit, and using UDP appropriately. However, you might miss the telltale glint in your customer's eyes when you told him "alternative X can be done in half the time, but it restricts the product to single Ethernets". The consequences of trying to hack a 'one-cable' design into a 'coast-to-coast' application are painful to the whole network. James B. VanBokkelen 26 Princess St., Wakefield, MA 01880 FTP Software Inc. voice: (617) 246-0900 fax: (617) 246-0901
bzs@world.std.com (Barry Shein) (07/24/90)
From: jbvb@vax.ftp.com (James B. Van Bokkelen) >One point I would add, Barry: You (or another ranking net.guru) would >be quite capable of recognizing a special case of the sort you posit, >and using UDP appropriately. However, you might miss the telltale >glint in your customer's eyes when you told him "alternative X can be >done in half the time, but it restricts the product to single >Ethernets". The consequences of trying to hack a 'one-cable' design >into a 'coast-to-coast' application are painful to the whole network. The penalty for stupidity is death. Glints in the eye merely carry heavy fines. -Barry Shein Software Tool & Die | {xylogics,uunet}!world!bzs | bzs@world.std.com Purveyors to the Trade | Voice: 617-739-0202 | Login: 617-739-WRLD