Reliability is one of those words that one always uses in a positive way. You don''t slander or insult someone by calling him or her reliable! Reliability is always an attribute that you can take pride in. In the world of networking, however, reliability takes on a different meaninga meaning that is neither good nor bad. Reliability is simply a description of a specific approach to delivering data rather than being a point of personal pride.
In a network, as explained throughout this book''s earlier chapters, you must choose between timely or reliable delivery of data. Sometimes you are lucky and get both timeliness and reliability, but that''s a pleasant bonus that you cannot count on. As a review, in the world of IP networking, the UDP protocol suite is used for timely delivery of data while TCP is used to guarantee delivery of data. You can''t have both!
To guarantee reliable delivery of data requires the sending and receiving machines to communicate with each other. Critical pieces of information must be exchanged. Important questions, such as "Did you receive that packet I sent you?" must be answered! Otherwise, there can''t be any guarantee other than "I''ll try once to get it to you, but don''t blame me if it doesn''t get there." Thus, it becomes obvious that two machines must be talking to each other for reliable delivery to be possible. The more technically accurate phrase for two-way conversation is session.
A session is a coherent flow of information between two or more machines. Coherent information flow requires a truly bidirectional flow of information. Information includes a whole lot more than just application data! Depending on the type of application you are using, it isn''t unrealistic for the flow of application data to be entirely one way. That is, the sender or source machine dumps packets of data onto the network. That would work just fine, and in fact is pretty much how UDP works. However, that one-way flow of information isn''t a session.Chapter 5, "Peeking Under the Covers," shows you). You see each one, as well as how they enable a source and destination machine to establish and manage a communications session.
Chapter 5) also come into use.
TCP''s header contains six fields that are just 1 bit each in length. You can''t put much into a single bit; that bit is either on (as indicated with a value of 1) or it''s turned off (as indicated with a value of 0). If you were limited to just one-word answers, such as Yes or No, you would have to ask your questions carefully! However, if you were limited to one-word answers and a total of just six questions, your life would be simple!
With TCP, that''s exactly the case. It''s a complex and robust protocol but you can boil down its operation to just six different questionseach of which is answered with the computer equivalent of a Yes or No. The source and destination machines aren''t so much asking questions as they are indicating whether a certain condition exists. If it exists, you wave that flag. If it doesn''t exist, you don''t wave the flag.
To refresh your memory, the six TCP flags are as follows:
URG or Urgent
SYN or Synchronize
ACK or Acknowledge
RST or Reset
PSH or Push
FIN or Finished Conversation
These six flags are more than enough to enable a source and destination machine to communicate and coordinate their activities. That might not be readily apparent, but it''s true! More to the point, these six flags work just as well for you in a verbal conversation as they do in a TCP/IP communications session. Both forms of conversation feature all the same attributes and impose the same type of requirements on both parties.
You walk through both types of conversation and see the similarities in the following sections. In this way, you can better appreciate the different aspects of a conversation, requirements or expectations for communication in that conversation, and some simple tools for facilitating the session. Using the analogy of a human conversation will help you better appreciate the significance of the TCP header''s six flags. Take a minute to revisit the names of those six flags and look for where they would come in handy during your verbal conversation. Then rerun that conversation using a different scenario: two computers using TCP/IP.
Here''s the scene: You are at a ballpark watching a baseball game and get the urge for some liquid refreshment. Initiating a conversation in a crowd can be a daunting affairespecially if you don''t know the person you want to converse with! You aren''t completely helpless, though. Fortunately, the stadium''s management has anticipated your needs and deployed an army of people who walk up and down the aisles yelling "Beer here!" Depending on what wares they are vending, they might opt for a slight variation on that chant. Either way, you get the picture.
The next piece of good news is that chances are both you and the beer industry''s answer to Gunga Din speak at least part of the same language. Assuming you''ve both been to a ballgame before, you both are familiar with the informal protocol that exists for buying beverages from the discomfort of your seat.
Generally speaking, your conversation might undergo three main stages:
Initiating the conversation, which includes receiving an acknowledgment that you have, indeed, caught that person''s attention and that the conversation can begin
Conversing with another person
Signaling that the conversation is over
Although this list isn''t comprehensive, it does give you a nice overview of the different stages that you can experience during a real-life conversation. During a real conversation, things don''t always go as planned. You might contend with outside factors that directly but temporarily impede your ability to converse. Such conditions mean a conversation might experience a couple other minor stages:
Informally negotiating the pace at which you two can communicate and the sophistication level of each other''s vocabulary. Big words don''t always impress!
Occasionally repeating yourself if the noise of the crowd drowns out your words. (Gunga will likely look at you funny or say something clever such as "What?" to indicate the failure of your previous transmission.)
Pausing the conversation to tend to immediate needs that might arise.
Restarting the conversation at or around where you left off before you were interrupted.
Take a closer look at these stages. Later sections translate them into TCP/IP for you.
Your first challenge in your quest to procure liquid refreshment is to actually get Gunga''s attention! The good news is that he''s a highly trained professional and instinctively recognizes a thirsty fan. That''s a good thing because, at least initially, you don''t know his name and he doesn''t know yours! You might well get to be best friends by the 7th inning, but at first you are just another part of the sea of humanity. Plus, he''s got quite a bit of territory to cover and doesn''t have the time or patience to go seat to seat asking each individual whether he is thirsty. He merely makes himself available and responds to requests.
The burden is, therefore, on you to initiate the conversation. You can do that in a multitude of ways such as yelling at him, raising your hand, catching his eye and nodding your head, or even just walking up to him. Regardless, you are the one who must start the conversation. When you think about it, that''s not much different from the way that your favorite Internet website works! Unless your computer is infected with a virus or spyware, you are the one that must start the communications session using TCP/IP to your favorite website. The website makes itself available via the Internet, and waits for your request to start communicating.
It''s not enough to think you have established contact with Gunga; you need to be sure! The only way to be sure is if you can get him to acknowledge your presence and your request. This is easy if you chose to just walk right up to him, but that''s not always possible. What would happen if you tried to signal him? You''d have to do something to stand out from the crowd and get his attention. More importantly, you would need some confirmation that your request to initiate a conversation has been received and accepted. Only then can you move on to the conversation itself.
The same basic pattern holds true for TCP. Reliable communications require the source and destination machines to synchronize their activities and to acknowledge that they are communicating properly.
After you''ve gotten Gunga''s attention, you carefully assess the situation to make sure you are communicating effectively. That means figuring out the following:
How loudly to speak
How quickly to speak
Choosing your words carefully so you''re not insulting the man before completing the transaction
In a real conversation with a stranger, much of this happens automatically. You negotiate these finer points without even realizing that you are doing it. This type of negotiation is critical if the two of you are to communicate effectively. In a real TCP/IP communications session, you don''t need to worry about many of the subtle points of human communications, but there are some direct analogies. For example, TCP/IP contains mechanisms to regulate the speed of communications. That''s important because sometimes a network gets busy and attempts to talk quickly will only fail.
Trying to hold a conversation in a crowded ballpark is a lot like trying to access a website on the Internet via a low-grade connection. You have to contend with a lot of noise and will likely have to often repeat yourself to compensate for the poor connection between yourself and your conversation partner.
The two keys to successfully repeating yourself are when to repeat yourself as well as what to repeat. Unless you are a psychic and can read other people''s minds, this absolutely requires some interaction with your conversation partner. Most often in this setting you will be told explicitly to repeat yourself via a gruff "What?"
Of course, there''s a subtle trap lying in wait in this scenario. What if the request to repeat also gets lost? In such cases, you can infer the need to repeat based on the lack of a response. Gunga hasn''t explicitly asked you to repeat yourself, but it''s not too tough to tell when someone you are talking to has completely missed what you said. This is equally true in a TCP/IP communications session. The key in both scenarios is to keep track of what you said and how much of that has been acknowledged. TCP allows you to track a session''s progress using sequence numbers.
Sometimes, but not always, something happens that requires your immediate attention. Regardless of how important your conversation with Gunga, you might have to drop it without much warning and pay attention to a more pressing priority.
For example, you have several important things to communicate while negotiating the purchase of your beer: what brand and variety you would like and whether Gunga actually carries that particular brew.
However, during the course of this communications session a foul ball might be hit right at you. As important as your conversation with Gunga is, the news of an impending impact would have to take priority! For example, if someone yells "Duck!" you should probably forget about whatever you and Gunga were discussing to process and act upon this new task immediately. In TCP/IP, the equivalent of that yell is known as an urgent packet and qualifies for priority handling.
After so close a call, you might have temporarily forgotten what you were doing before your emergency self-preservation tactics. Perhaps you put up your mitt and caught the ball, in which case you are now preoccupied with showing off your trophy and hamming it up for the camera crew. Perhaps you merely hid behind your significant other in which case it''s now more urgent than ever that you return your focus to your transaction with Gunga.
For the purposes of your conversation with Gunga, how you reacted doesn''t matter. What does matter is that the sudden surge of adrenaline and excitement derailed your train of thought. Fortunately, Gunga is still there, waiting to complete the transaction. You can count on him to refresh your memory and facilitate getting the conversation back on track.
The same thing is true with computers that communicate using TCP/IP. You would have lost your session and would need to reestablish it using the Reset or RST flag.
Eventually all things must come to an end. So, too, must your interaction with Gunga. You might be his most important customer, but you''re not his only one. He''s probably got thousands of other potentially thirsty customers to satisfy. You and Gunga needn''t stand on ceremony or exchange heartfelt hugs of thanks before parting ways, but you do need to convey to each other that both the conversation and transaction are over.
From Gunga''s perspective, he''s now free to look for other customers to satisfy. From your perspective, you can now get back to the game or merely drown your embarrassment at having clanked that foul ball.
TCP/IP communications sessions, too, must end gracefully. A specific sequence of events allows both the source and destination machines to agree that the session is over.
This example of an attempt to buy a beer at a ballgame is more than just page filler. It demonstrates all a conversation''s stagesmajor and minorand strongly resembles a real Internet-based communications session. To briefly recap
You found a way to signal to the seller that you needed his services.
The seller acknowledged your request to start a conversation.
The two of you quickly established the appropriate volume, speed, and vocabulary that would enable you to complete the transaction.
The two of you carried out the conversation in which you communicated all your needs to the seller and he responded by providing both confirmation that he received and understood your request, as well as any additional information you might have requested (such as confirming the brands, prices, and so on).
The sample conversation also included error conditions:
You realized you needed to repeat yourself when the din (pardon the double entendre) of the crowd drowned you out.
The foul ball caused you to lose track of what you were doing. In fairness, that was a much higher priority and demanded immediate attention, which is why both the rules of etiquette and TCP/IP allow for putting a conversation back on track after so justifiable a distraction.
Now that you are much more familiar with the official parts of a conversation, as well as some of the more common error conditions that could disrupt a conversation, it''s time to look a bit more closely at those six little TCP/IP flags and how they are used in a real communications session. Hopefully, you immediately recognize and appreciate the similarities between your conversation with Gunga and the communications session.
The many similarities between communicating in a crowd and communicating in a network are quite startling. The critical parts of a conversation described for you earlier in this chapter are universally required, and that holds true for people talking in a stadium as well as computers talking across a network.
Here''s the scenario. Instead of you trying to purchase a beer from a vendor at a ballgame, assume you are purchasing a case of beer directly from the microbrewery via the Internet. Thus, instead of dealing with Gunga the person, you are dealing with an Internet website, which serves a similar purpose for a different audience. The conversation''s various stages remain remarkably constant as you make the transition from a live conversation to a TCP/IP communications session.
Your challenge for starting a conversation remains: How do you get the attention of a server that sits on the Internet? By now you should already recognize the futility of trying to guess its IP address. The odds are roughly 4,000,000,000 to 1 against you! Fortunately for you, the Internet Engineering Task Force (IETF) and many other Internet entrepreneurs have anticipated your needs and deployed a wide array of tools for your use.
If you know the name of the microbrewery''s website, you could simply enter that in your browser. Or you can search for the name of that company or its products in any one of the countless Internet search engines. That will help you find the server you are seeking, but you still need to get its attention.
As with Gunga in the stadium, you must also know that you''ve caught the server''s attention rather than simply assume that you have it. This requires an acknowledgment from that distant server. Although that much tracks neatly with your personal conversation, there is an added twist: TCP is a reliable protocol and reliable delivery means confirmation of delivery. Thus, it''s not quite enough that you have received an acknowledgment from the microbrewery''s website server; you must also acknowledge your receipt of its acknowledgment! That probably sounds a bit complicated, but it is how TCP can guarantee reliable delivery.
That three-part process is how every TCP/IP session begins. In fact, it''s known as the three-way handshake. To make this a bit more real, get back to those six flags mentioned earlier. The first step in establishing a communications session using TCP/IP is for you to send out a single packet of data to your intended destination.
That packet bears no application data but instead conveys two critical pieces of information in just the header fields:
The pattern of flag bits. One of the six little flags has been set to 1. That flag is SYN. All the other flags are still set to 0. The pattern of bits in the flags section of the TCP header would look like 000010 because the SYN flag is the fifth of the six.
A new serial or sequence number from your computer. To help you better appreciate the significance and purpose of the sequence number, assume you just sent sequence number 618. Figure 8-1 shows your computer trying to establish a communications session with the microbrewery''s server.
The server''s reply would contain two critical pieces of information: that server''s sequence number (assume that this number is 916) and both the SYN and ACK flags would be set. The pattern of bits in this response or acknowledgment packet would be 010010. This is shown in Figure 8-2.
|
The last piece of the three-way handshake would be for you (or your computer, more precisely) to acknowledge the acknowledgment. Your acknowledgment would be similar to those just shown; it would feature the same two critical pieces of informationsequence number and flags.
The sequence number used would be one digit greater than was used in the original SYN packet. Therefore, if your computer originally generated the SYN packet with a TCP sequence number of 618, this ACK would bear sequence number 619. Each subsequent packet generated in this session between you and the microbrewery would increment the sequence number by 1.
The actual bit pattern in the TCP header''s flag field, however, would be different than those you''ve just seen. That''s logical when you consider that this is the third part of the three-way handshake. The pattern of flags in this acknowledgment is 010000. If you reflect back on the structure of the flags field shown earlier in this chapter, you see that the only flag actually set is the ACK or Acknowledge flag. This is illustrated in Figure 8-3.
The next part of the conversation features the exchange of information. Even if you''re having a conversation with the chattiest person in the world, that person will occasionally pause long enough for you to acknowledge the influx of information…or maybe just prove you are still awake! That confirmation is known as an acknowledgment. Acknowledgments are a critical component of a TCP/IP session.
The TCP sequence numbers do far more than just complicate the establishment of a communications session. They are the mechanism that enables reliable delivery to be reliable. They keep track of data both transmitted and received in a communications session. The sequence numbers don''t have to match each other, but each computer needs to track the sequence numbers that it generates and the sequence numbers of incoming packets.
The terminology that describes the chunks of data created by TCP/IP can be confusing and is often misused. The three key terms you need to know are segment, packet, and datagram.
TCP chops up data received from applications into more manageable chunks. Each chunk is known as a segment. TCP prepends each segment with a header and hands it off to IP for further processing. Thus, a segment can refer to either a raw chunk of data or a chunk of data prepended with a TCP header. IP, of course, puts its own header in front of that data segment. That mechanism is known as a packet.
A datagram is a single unacknowledged packet of information sent over a network as an individual packet without regard to previous or subsequent packets. This definition can apply to packets bearing both TCP and UDP, but the phrase unacknowledged implies UDP only. For that reason, UDP packets are often referred to as datagrams, while TCP packets are called segments.
Because IP encapsulates both UDP and TCP, a packet can contain both segments and datagrams.
Keeping track of both sets of sequence numbers forms the basis of reliable delivery. By using a process of elimination, a computer can figure out if it is missing pieces of data that it should have already received. To continue with the previous example, your computer had used sequence numbers 618 and 619 to establish a communications session with the microbrewery''s website. That destination computer had started with sequence number 916. Thus, your next TCP packet in this session will be numbered 620 and the next packet you receive from the website should be numbered 917.
Notice that says should be. There''s no guarantee that the next packet you receive will actually be sequence number 917. You might never receive it if, for example, that packet timed out or was damaged in transit. However, you will notice it''s missing when you receive a TCP packet from that same computer bearing the TCP sequence number 918 or higher. By keeping track of which packets have been received, it is possible to deduce which packets have not been received.
Your computer indirectly communicates the news about packets not received. Rather than send out the alarm and specifically request a new copy of whatever data was stamped with TCP sequence number 917, your computer acts a bit more discretely. It simply doesn''t acknowledge sequence number 917 as having been received. That puts the onus back on the other computer to recognize that 916 has been acknowledged (as has 918, 919) but that 917 must be presumed missing. Consequently, a new copy of it is generated and re-sent. That''s what reliable delivery is all about!
One of the more minor aspects of a conversation is gearing your words and rate of speech toward your audience. You need to find a common ground or else the conversation just won''t be productive. In human beings, this is almost a subconscious skill. It is ever-present in conversations, particularly when you are talking with people you don''t know. You need to figure out how sophisticated that person is, how extensive her vocabulary might be, and even how quickly she speaks. All this useful information helps you tailor your speaking to your audience. Failing to do this risks alienating the person you are trying to converse with and even prematurely ending the conversation.
Computers that speak TCP are no different. It''s safe to assume that both computers speak exactly the same language, so there''s no worry about vocabulary. However, potential discrepancies lie in the hardware. Using the example of accessing a website across the Internet nicely demonstrates the potential for a hardware mismatch.
You might still be limping along on a Pentium III class machine at home. It has plenty of life left in it, but it''s hardly a match for an enterprise-class server such as the one the microbrewery uses. That''s perfectly logical. You are just using your computer to surf, e-mail, and chat, but the microbrewery''s server is critical to its mission.
If that machine fails, sales stop! So it is perfectly logical for that enterprise to spend a lot more on their computing hardware than you do. Plus, there is a whole lot of networking equipment that makes up the physical path between your PC and that server on the Internet. Each of those devices (known more properly as routers) can vary widely in their abilities. Thus, it is imperative that TCP enable two computers to find some common ground as they try to establish a communications session.
The common ground as far as TCP is concerned focuses on how much data the two machines can handle and negotiating a pace that works for both machines. Although that might seem like just one thing, it really has two sides:
How many TCP segments can be sent without requiring an acknowledgment of receipt from the other machine
How much data each segment can contain
Determining how quickly each machine in a TCP communications session can talk is a prerequisite to a good session. If one machine is much more powerful than the other, it would be easy to overload that smaller, less capable machine. TCP evens out these possible disparities by making sure that both machines agree to a maximum amount of data sent without acknowledgment. This mechanism is known as the TCP window size.
The TCP window size identifies the amount of data that can be sent without first getting an acknowledgment. This limit is tracked in terms of octets. An octet is 8 bits of data, which is usually the same size as 1 byte of data. Therefore, a window size of 1024 allows you to send 1,024 octets or bytes without receiving an acknowledgment.
Although this is cast as a mechanism to even out differences in computing platforms, this capability has several uses:
Fine-tuning an application''s performance by manipulating the amount of data it can send unacknowledged. When a network is not being heavily used, you can send larger quantities of data. When a network is busy, it has less capacity available for your communications session. Consequently, it is important for a source and destination machine to establish the rate at which they can communicate through a network.
Reacting to changes in the health of a network. If, for example, the network is suffering severe congestion, reducing the TCP window size can help relieve that congestion by throttling back the amount of data that any given computer sends.
It''s important to note that, unlike all other TCP attributes shown throughout this chapter, TCP window sizing isn''t set per application or per packet. It is more a computer-level attribute. Thus, when establishing a window size, you are establishing it for all applications on that computer that rely on TCP/IP to communicate.
The term sliding window refers to a dynamic approach to controlling TCP window size. Rather than hard code the window size, it makes sense to allow TCP to figure out the right window size based on network performance. In other words, the window''s actual size can slide up or down in response to changes in the network''s state.
The second aspect of a negotiated data transmission pace is the one more directly useful in negotiating the setup of a communications session. This one is actually an option that can be set in each TCP header and it conveys the maximum size that a segment can be. That limitation, known as maximum segment size, is usually set to the largest possible value by default, but can be modified to fine-tune network performance for a specific application. The TCP header''s maximum segment size field tells the destination machine exactly how large a TCP segment it can accept. This value is specified in bytes.
|
For now, that''s all you need to know about negotiating the pace of a communications session, so let''s get back to those flags. You still have three left to explore!
Truth be told, some applications just don''t tolerate delays welleven those that require guaranteed delivery! For example, you might be using online chat or Instant Messenger software. Those packages work a lot like the old terminal emulation software. In the halcyon days of computing, before Microsoft turned computing into a drag-and-drop video game, you would use a command-line interface (CLI) to log onto and use computers.
The CLI would not be data intensive; you would literally type a character and see it appear on the command line. If you were to type with any kind of confidence, it was imperative that your keystrokes get displayed on the screen promptly! That was the original motivation for TCP''s third of the six flags, known properly as the PSH or Push flag. The point is that TCP provides a mechanism for your applications to use when they require a higher priority processing. Packets received with the PSH flag set are processed immediately. Up to now, a simple rule differentiated between TCP and UDP. Applications that require timely delivery use UDP, and applications that require guaranteed delivery use TCP. At first glance, those appear to be almost mutually exclusive goals. They are clearly different enough to warrant the use of different tools (i.e., TCP and UDP), but they really aren''t mutually exclusive. There are applications that require both! Applications that operate much like the old command-line interface include text-based communications software such as Instant Messaging (IM) or Internet chat. For such applications, the only real choice is to use TCP and wave the PSH flag.
Packets that have the Push flag set (it''s the third of the six bits, so the flag pattern in a Push packet is 001000) require a receiving machine to give it priority handling. A machine receiving a Push packet would immediately process and hand it off to the appropriate application, such as chat or IM.
Under normal circumstances, TCP would prefer to hang onto the received data for reassembly with other received data into a larger structure such as a complete file. Hanging onto a packet that contains just a few characters could cause problems for the user of time-sensitive applications such as IM, so the Push flag signals that TCP should immediately pass it on.
|
It''s not just children who require a do-over when something goes wrongTCP does, too! Of course, it''s not called a do-over. That wouldn''t be professional. Instead, two mechanisms are used when something goes awry in a TCP communications session. These two mechanisms provide the following:
The ability to retransmit an individual packet if it should time out before reaching its destination
The ability to reset the session if communications are lost between the source and destination machines
TCP/IP automatically does many things for you when you start a communications session. One of those things is track the time it takes to send a packet to a remote destination and to receive a response. That amount of time is known as round trip time (RTT).
TCP adds a small amount of time to RTT to develop a threshold within which it can safely assume that all acknowledgments will have been received. TCP uses sequence numbers to keep a running tally of packets sent and packets acknowledged. Packets that were sent but not acknowledged within the RTT threshold are considered lost, and must be retransmitted. Packets transmitted but not acknowledged within the RTT are said to have timed out.
|
Recovering from a lost or defunct connection is a bit different from simply retransmitting a timed-out packet. For one thing, the entire session is at stake rather than just one piece of data. Another thing to remember is that resetting a session requires the use of one of the six TCP header flags. That flag, RST, is the fourth of the six in that header field.
A variety of error conditions can cause a host to reject a session, and an empty RST packet is sent to convey the news of that nameless error. From the other machine''s perspective, it doesn''t really matter what went wrong; all that''s really important is that the session has been terminated and a new one must be negotiated. That means that if the communications between hosts are to continue, a new session must be negotiated via the three-way handshake.
The RST flag might also be used as part of the three-way handshake to reject a request to start a session. For example, instead of replying to an SYN request, a computer can respond with RST. When that happens, the request to establish a connection is rejected.
Lastly, even the best and most enjoyable of conversations must come to an end eventually. When that happens, it''s customary to signal to your conversation partner that you''re done talking. It doesn''t matter how you actually end the conversation, just so long as you signal that you''re done talking. So, too, must TCP/IP gracefully conclude its communications sessions. This is done through the use of a Finish packet.
When an application''s job is done, either the user logs out of the application or the task of pushing data to a remote computer reaches completion. Either way, the application will tell TCP that it''s done. This is TCP''s cue to shut down the session. It does so by generating another empty packet (one that contains no application data). This empty packet lets the destination machine know the session is over via the flags.
The last of the six flag bits is known as the FIN or Finish flag. That empty packet bears the flag bit pattern of 000001 and is known as a Finish or FIN packet. That destination machine must acknowledge that it has received this packet. The response packet, however, is quite special. Its flags are set so that both the FIN and ACK flags are on. This acknowledgment packet''s actual flag bit pattern is 010001. That packet is consequently known as a Finish-Acknowledgment or FIN-ACK packet.
Wait, we''re not done yet! The source machine (the one that generated the first FIN packet) must acknowledge this acknowledgment packet. That acknowledgment has to have both the ACK and FIN flags set, too. Only after this pair of Finish-Acknowledgment packets is exchanged can the session be shut down.
|