Datagrams and Multicasting (Part 1)
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
TCP Versus UDP
The Internet uses Transaction Control Protocol (TCP) for most communications. TCP is one of several protocols in the TCP/IP stack; each protocol fits a specific need or function, providing different capabilities and different levels of reliability (see Figure 1). Determining when to use one protocol or another depends on the data itself.
){kind=link}
Figure 1 The Internet Protocol network layers.
TCP makes the endless sequence of messages (packets) appear like a continuous flow of bi-directional, highly reliable data. The direct benefit is data reliability and streaming. A streaming communications channel appears to be a continuous flow of information, like two people talking on a telephone. While greatly useful, TCP adds a lot of overhead for handshaking between the two hosts, and that may not be what you want in sending messages, especially in this time of increased peer-to-peer (P2P) transmissions.
User Datagram Protocol (UDP), on the other hand, lets you send and receive individual datagrams, which are a sequence of packets grouped into discrete messages. Datagrams are very fast, requiring no handshaking overhead. But datagrams are similar to passing notes in the classroom. Each note is self-contained, having the destination and source addresses and the body of the message. Just as with passing notes, you can't be sure that the message gets to the destination, that its contents are unrevised during transit, and that only the recipient reads the contents.
TCP can guarantee the integrity of the communication path, but can't prevent snooping. Still, TCP is essentially continuous; the snooper would have to listen to the whole conversation. By contrast, the datagram message is self-contained, and therefore easier to decipher.
Finally, TCP ensures that the data that the reader gets exactly what was sent, in the right order. UDP offers no such guarantees. Transferring files may not be a good use of UDP, because you probably can't send the whole file all at once. The datagram is limited to less than 64KB of data; a program designed to transmit a file would have to break it up into smaller pieces and send each piece in succession. Even sending individual pieces may not work, though, because UDP doesn't ensure that the datagrams would arrive in the same order as they were sent—or even arrive at all.
For all its limitations, UDP is very efficient and fast. Two data types lending themselves very well to datagrams are temporal data (useful for a time period) and audio/visual samplings. Current weather conditions, the correct time, and current stock prices are all examples of temporal data: Once the server takes the next sampling, previous data is less meaningful.
Audio/visual samplings fit rather nicely into datagram protocols. Like temporal data, audio and visual sampled data loses importance or significance when the next sample is taken. The network or client can drop samples without degrading too badly what the person sees and hears. As you program tools for P2P communications, you can take advantage of the brain's capability to fill in gaps. As a direct example, a server can send an audio stream in something like two channels. One channel is low quality (4 kilobytes/second raw sampling), and the second channel is high quality (32 kilobytes/second raw sampling). Each channel represents the same timeframe—but the second channel generates eight times the amount of data. With this format, you can use the first channel as a scaling factor for the second channel, thus increasing compression. Also, if either channel's packet gets lost in the network, the other channel would pick up the slack. UDP's fast but unreliable data flow is a natural fit in A/V streaming.