| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
UDP Common Applications and Server Port Assignments (Page 2 of 3) Why Some TCP/IP Applications Use UDP What applications use UDP then? Well, the classic disclaimer with UDP is that since it doesn't provide the features we saw earlier, an application that uses UDP is responsible for those functions. In reality, if an application needs the features that TCP provides but UDP does not, having the application implement them is inefficient, except in special cases. If the application needs what TCP provides, it should just use TCP! However, applications that only need some of what TCP implements are sometimes better off to use UDP and implement that limited set of functionality at the application level. So, the applications that run over UDP are normally those that do not require all or even most of the features that TCP has, and that can benefit from the increased efficiency of avoiding the setup and overhead associated with TCP. Applications usually (but not always) meet this description because the data they send falls into one of two categories. The classic example of this category is a multimedia application. If you are streaming a video clip over the Internet, the most important thing is that the stream starts flowing quickly and keeps flowing. Humans only really notice significant disruptions in the flow of this type of information, so a few bytes of data missing due to a lost datagram is not only not a big problem, it's unlikely to even be noticed. Furthermore, even if TCP were used for something like this and a lost datagram was noticed and retransmitted, it would be useless because it would belong to a part of the clip that is long pastand the time spent in that retransmission might make the actual current part of the clip arrive late. Clearly, UDP is best for this situation. There are many TCP/IP applications where the underlying protocol consists of only a very simple request/reply exchange. A short request message is sent from a client to a server, and a short reply message goes back from the server to the client. In this situation, there is no real need to set up a connection like TCP does. Also, if only one short message is sent, it can be carried in a single IP datagram. This means there is no need to worry about data arriving out of order, flow control between the devices and so forth. How about loss of the request or the reply? These can be handled simply at the application level using timers. If a client sends a request and the server doesn't get it, it won't reply, and the client will eventually send a replacement request. The same logic applies if the server sends a response that never arrives. As I said before, these are the most common cases where UDP is used, but there are other reasons. For example, if an application needs to multicast or broadcast data, it must use UDP, because TCP is only supported for unicast communication between two devices.
Home - Table Of Contents - Contact Us The TCP/IP Guide (http://www.TCPIPGuide.com) Version 3.0 - Version Date: September 20, 2005 © Copyright 2001-2005 Charles M. Kozierok. All Rights Reserved. Not responsible for any loss resulting from the use of this site. |