| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
TCP Data Handling and Processing: Streams, Segments and Sequence Numbers (Page 1 of 3) One of the givens in the operation of most of the protocols we find at upper layers in the OSI Reference Model is that they are oriented around the use of messages. These messages are analogous to a written letter in an envelope, containing a specific piece of information. They are passed from higher layers down to lower ones, where they are encapsulated in the lower layer's headers (like putting them in another envelope) and then passed down further until they are actually sent out at the physical layer. A good example of this can be seen in looking at the User Datagram Protocol, TCPs transport layer peer. To use UDP, an application passes it a distinct block of data that is usually fairly short. The block is packaged into a UDP message, then sent to IP. IP packs the message into an IP datagram and eventually passes it to a layer two protocol such as Ethernet. There it is placed into a frame and sent to layer one for transmission. The use of discrete messaging is pretty simple, and it obviously works well enough since most protocols make use of it. However, it is inherently limiting, because it forces applications to create discrete blocks of data in order to communicate. There are many applications that need to send information continuously in a manner that doesn't lend itself well to creating chunks of data. Others need to send data in chunks that are so large that they could never be sent as a single message at the lower layers anyway. To use a protocol like UDP, many applications would be forced to artificially divide their data into messages of a size that has no inherent meaning to them. This would immediately introduce new problems requiring more work for the application. It would have to keep track of what data is in what message, and replace any that were lost. It would need to ensure that the messages could be reassembled in the correct order, since IP might deliver them out of order. Of course, one could program applications to do this, but these functions are already ones that TCP is charged with taking care of, so it would make little sense. Instead, the designers of TCP took the very smart approach of generalizing TCP so it could accept application data of any size and structure, without requiring that it be in discrete pieces. More specifically, TCP is said to treat data coming from an application as a stream; thus, the description of TCP as stream-oriented. Each application sends the data it wishes to transmit as a steady stream of octets (bytes). It doesn't need to carve them into blocks, or worry about how lengthy streams will get across the internetwork. It just pumps bytes to TCP.
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. |