Please Whitelist This Site?

I know everyone hates ads. But please understand that I am providing premium content for free that takes hundreds of hours of time to research and write. I don't want to go to a pay-only model like some sites, but when more and more people block ads, I end up working for free. And I have a family to support, just like you. :)

If you like The TCP/IP Guide, please consider the download version. It's priced very economically and you can read all of it in a convenient format without ads.

If you want to use this site for free, I'd be grateful if you could add the site to the whitelist for Adblock. To do so, just open the Adblock menu and select "Disable on tcpipguide.com". Or go to the Tools menu and select "Adblock Plus Preferences...". Then click "Add Filter..." at the bottom, and add this string: "@@||tcpipguide.com^$document". Then just click OK.

Thanks for your understanding!

Sincerely, Charles Kozierok
Author and Publisher, The TCP/IP Guide


NOTE: Using software to mass-download the site degrades the server and is prohibited.
If you want to read The TCP/IP Guide offline, please consider licensing it. Thank you.

The Book is Here... and Now On Sale!

Read offline with no ads or diagram watermarks!
The TCP/IP Guide

Custom Search







Table Of Contents  The TCP/IP Guide
 9  TCP/IP Lower-Layer (Interface, Internet and Transport) Protocols (OSI Layers 2, 3 and 4)
      9  TCP/IP Transport Layer Protocols
           9  Transmission Control Protocol (TCP) and User Datagram Protocol (UDP)
                9  TCP/IP Transmission Control Protocol (TCP)
                     9  TCP Fundamentals and General Operation

Previous Topic/Section
TCP Data Handling and Processing: Streams, Segments and Sequence Numbers
Previous Page
Pages in Current Topic/Section
123
4
56789
Next Page
TCP Ports, Connections and Connection Identification
Next Topic/Section

TCP Sliding Window Acknowledgment System For Data Transport, Reliability and Flow Control
(Page 4 of 9)

Improving the Utility of PAR Through Message Identification and Send Limits

PAR is a technique that is used widely in networking and communications for protocols that exchange relatively small amounts of data, or exchange data infrequently. The basic method is functional, but it is not well-suited to a protocol like TCP for two reasons. The first is that it is inefficient. Device A sends a message and then waits for the acknowledgment. Device A cannot send another message to Device B until it hears that its original message was received, which is very wasteful and would make the protocol extremely slow.

The first improvement we can make to this system is to provide some means of identification to the messages sent and to the acknowledgments. For example, we could put a message ID field in the message header. The device sending the message would uniquely identify it, and the recipient would use this identifier in the acknowledgment. For example, Device A might send a piece of data in a message with the message ID #1. Device B would receive the message and then send its own message back to Device A saying “Device A, I received your message #1”. The advantage of this system is that Device A can send multiple messages at once. It must keep track of each one sent, and whether or not it was acknowledged. Each also requires a separate timer, but that's not a big problem.

Of course, we also need to consider this exchange from the standpoint of Device B. Before, it only had to deal with one message at a time from Device A. Now it may have several show up all at once. What if it is already busy with transmissions from another device (or ten)? We need some mechanism that lets Device B say “I am only willing to handle the following number of messages from you at a time”. We could do that by having the acknowledgment message contain a field, such as send limit, which specifies the maximum number of unacknowledged messages A was allowed to have in transit to B at one time.

Device A would use this send limit field to restrict the rate at which it sent messages to Device B. Device B could adjust this field depending on its current load and other factors to maximize performance in its discussions with Device A. This enhanced system would thus provide reliability, efficiency and basic data flow control, as illustrated in Figure 205.


Figure 205: Enhanced Positive Acknowledgment With Retransmission (PAR)

This diagram shows two enhancements to the basic PAR scheme of Figure 204. First, each message now has an identification number; each can be acknowledged individually, so more than one can be in transit at a given time. Second, device B regularly communicates to A a send limit parameter, which restricts the number of messages A can have outstanding at once. B can adjust this parameter to control the flow of data from A.

 


Key Concept: The basic PAR reliability scheme can be enhanced by identifying each message to be sent, so multiple messages can be in transit at once. The use of a send limit allows the mechanism to also provide flow control capabilities, by allowing each device to control the rate at which it is sent data.



Previous Topic/Section
TCP Data Handling and Processing: Streams, Segments and Sequence Numbers
Previous Page
Pages in Current Topic/Section
123
4
56789
Next Page
TCP Ports, Connections and Connection Identification
Next Topic/Section

If you find The TCP/IP Guide useful, please consider making a small Paypal donation to help the site, using one of the buttons below. You can also donate a custom amount using the far right button (not less than $1 please, or PayPal gets most/all of your money!) In lieu of a larger donation, you may wish to consider purchasing a download license of The TCP/IP Guide. Thanks for your support!
Donate $2
Donate $5
Donate $10
Donate $20
Donate $30
Donate: $



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.