.

Saturday, September 21, 2019

The Tcp Service Model Information Technology Essay

The Tcp Service Model Information Technology Essay The transport service is implemented by a transport protocol used between two transport entities. The transport protocol have to deal with error control, sequencing, and flow control. UDP is a simple protocol and it has some niche uses, such as client-server interactions and multimedia, but for the most Internet applications, reliable, sequenced delivery is needed.UDP cannot provide this, so another protocol is required. It is called TCP and is the main workhouse of the internet. THE TCP SERVICE MODEL: TCP service is obtained by both the sender and receiver creating end points, called sockets. A socket may be used for multiple connections at the same time. All TCP connections are full duplex and point to point. Full duplex means that the traffic can go in both directions at the same time. Point-to-point connection contains exactly two end points. Another feature of the TCP service is URGENT DATA. When the urgent data are received at the destination. The receiving application is interrupted so it can stop whatever it was doing and read the data stream to find the urgent data. The start of the urgent data is not marked while the end is marked so the application knows when it is over. This scheme basically provides a crude signaling. THE TCP PROTOCOL: A key feature of TCP, and one which dominates the protocol design, is that every byte on a TCP connection has its own 32-bit sequencer. When the internet began, the lines between routers were mostly 56-kbps leased lines, so a host blasting away at full speed took over 1 week to cycle through the sequence numbers. Separate 32-bit sequence numbers are used for acknowledgements and for the window mechanism. The sending and receiving TCP entities exchange data in the form of segments. What should a segment have? 1.Each segment including the TCP header, must fit in the 65,515-bytes IP payload. 2.Each network has a maximum transfer unit, or MTU, and each segment must fit in the MTU. THE TCP SEGMENT HEADER: The following is the dissection of TCP header field by field. The Source port and Destination port fields identify the local end points of the connection. The source port number is of 16 bits and indentifies the sending host TSAP(client port number). The destination port number is of 16 bits and is used to identify the receiver host TSAP(server port number). The sequence number is of 32 bits size. Since TCP supports Byte-stream, in which each byte is numbered, big space is allocated for numbering i.e.(2 power 32=4096 million).With the help of these numbers only ,one can be able to differentiate the old delayed duplicate with fresh ones. The acknowledgement number is of 32 bits size. It specifies the next byte expected. The length of TCP header is of 4 bits size and indicates the number of rows. Next comes a 6-bit field that is UNUSED. The fact that this field has survived intact for over a quarter of a century is testimony to how well thought out TCP is. Lesser protocols would have needed it to fix bugs in the original design. Six 1-bit flags: 1. URG is set to 1 if the urgent flag pointer is in use. 2. The ACK bit is set to 1 to indicate that the acknowledgement number is valid. If ACK is 0, the segment does not contain an acknowledgement so the ACKNOWLEDGEMENT NUMBER is ignored. 3. The PSH bit indicates pushed data. 4. The RST bit is used to reset a connection that has become confused due to a host crash or some other reason. It is also used to reject an invalid segment or refuse an attempt to open a connection. In general, if you get a segment with the RST bit on, you have problem on your hands. 5. The SYN bit is Synchronization flag. It is used to establish connections. The connection request has SYN=1 and ACK=0 to indicate that the piggyback acknowledgement field is not in use. The connection reply does bear an acknowledgement, so it has SYN=1 and ACK=1. 6. The FIN bit is finish flag. It is used to release a connection. It specifies that the sender has no more data to transmit. CHECKSUM: A checksum is also provided for extra reliability. It checks the header, the data and the conceptual pseudoheader. When performing this computation, the TCP Checksum field is set to zero and the data field is padded out with an additional zero byte if its length is an odd number. PSEUDOHEADER: The pseudoheader contains the 32-bit IP addresses of the source and destination machines, the protocol number for TCP (6), and the byte count for the TCP segment. Including the pseudoheader in the TCP checksum computation helps detect misbelieved packets. TCP CONNECTION MANAGEMENT MODELING: The steps required to establish and release connections can be represented in a finite state machine with the 11 states listed below. In each state, certain events are legal .when a legal event happens, some action may be taken. If some other event happens, an error is reported. State Description CLOSED No connection is active or pending LISTEN The server is waiting for an incoming call SYN, RCVD A connection request has arrived: wait for ACK SYN SENT The application has started to open a connection ESTABLISH The normal data transfer state FIN WAIT 1 The application has said it is finished FIN WAIT 2 The other side has agreed to release TIMED WAIT Wait for all packets to die off CLOSING Both sides have tried to close simultaneously CLOSING WAIT The other side has initiated a release LAST ACK Wait for all packets to die off Each connection starts in the CLOSED state. When it performs either a passive open {LISTEN}, or an active open {CONNECT}, it leaves the state. If the other side does the opposite one, a connection is established and the state becomes ESTABLISHED. Connection release can be initiated by either side. The state returns to CLOSED, after it is completed. Description of the figure: The heavy solid line is the normal path for a client. The heavy dashed line is the normal path for a server. The light lines are unusual events. Each transition is labeled by the event causing it and the action resulting from it, separated by a slash. The event can either be a user à ¢Ãƒ ¢Ã¢â‚¬Å¡Ã‚ ¬initiated system call {CONNECT, LISTEN, SEND or CLOSE}, a segment arrival [SYN, FIN, ACK or RST}, or in one case, a timeout of twice the maximum packet lifetime. The action is the sending of a control segment {SYN, FIN or RST} or nothing, indicated by -.Comments is shown in parentheses. Figure: TCP connection management finite state machine. TCP TRANSMISSION POLICY: Windows Management in TCP is not directly tied to acknowledgements as it is in most data link protocols. If the sender transmits a 2048-byte segment that is correctly received, the receiver will acknowledge the segment. However, since it now has only 2048 bytes of buffer space (until the application removes some data from the buffer), it will advertise a window of 2048 starting at the next byte expected. The window management in TCP is shown in the following figure. Now the sender transmits another 2048 bytes, which are acknowledged, but the advertised window is 0. The sender must stop until the application process on the receiving host has removed some data from the buffer, at which time TCP can advertise a larger window. Senders are not required to transmit data as soon as they come in from the application. When the first 2 KB of data came in, TCP, knowing that it had a 4 KB window available, would have been completely correct in just buffering the data until another 2KB came in, to be able to transmit a segment with a 4KB payload. This freedom can be exploited to improve performance. On the following grounds the sender com still send segments upon receiving the win=0(window size) or (buffer available). When the window=0;the sender may not normally send segments, with two exceptions i)URGENT DATA MAY BE SENT To allow the user to kill the process running on the remote machine. ii)The sender may send a 1byte segment to make the receiver re-announce the next byte expected and window size. SILLY WINDOW SYNDROME: To transmit 1byte of message TCP overhead 20 bytes, IP are required.In other words just to transmit 1 byte, extra 40 Bytes are required. Whenever there is a 1 byte room available at the receiver buffer, the window update segment is sent. Since the receiver is requested for 1 byte the sender sends 1 byte which leads to the receiver buffer to be full over again. Asking for 1 Byte and sending 1 byte appears to be silly, hence the name silly window syndrome. To avoid Silly window syndrome, Nagle suggested NAGLES APPROACH: When the data comes to the sender 1 byte at a time, just send the first Byte and buffer, all the rest until the outstanding Byte is acknowledged. Then send all the buffered characters in one 1 TCP segment and start buffering again until they are all acknowledged. Nagles approach cannot be implemented for all applications. In particular, when as X-windows application is being run over the internet, mouse movements have to be sent to the remote computer. Gathering them and sending them in bursts makes the mouse cursor more erratically, which makes users dissatisfied. CLARKS ALGORITHM: This approach is to prevent the receiver from sending a window update for 1byte instead, it is forced to wait until it has a decent amount of space available and then advertise that. Nagles algorithm is with respect to sender and Clarkà ¢Ãƒ ¢Ã¢â‚¬Å¡Ã‚ ¬Ãƒ ¢Ã¢â‚¬Å¾Ã‚ ¢s algorithm with respect to solve Silly window syndrome. The overall goal is for the sender not to send small segments and the receiver not to ask for them. TCP CONGESTION CONTROL: When the load offered to any network is more than it can handle, congestion builds up. The Internet is no exception. Although network layer also tries to manage congestion, most of the heavy lifting is done by TCP because the real solution to congestion is to slow down the data rate. In theory, congestion can be dealt with by employing a principle borrowed from physics: the law of conservation of packets. The idea is to refrain from injecting a new packet into the network until an old one leaves.TCP attempts to achieve this goal by dynamically manipulating the window size. The first step in managing congestion is detecting it. A timeout caused by a lost packet could have been caused by either (1) noise on a transmission line or (2) packet discard at a congested router. Nowadays, packet loss due to transmission errors is relatively rare because most long-haul trunks are fiber. All the Internet TCP algorithms assume that timeouts are caused by congestion and monitor timeouts for signs of trouble the way miners watch their canaries. TCP TIMER MANAGEMENT: TCP uses multiple timers to do its work. The most important of these is the retransmission timer. When a segment is sent, a retransmission timer is started. If the segment is acknowledged before the timer expires, the timer is stopped. If, on the other hand, the timer goes off before the acknowledgement comes in, and the segment is retransmitted. A second timer is the persistence timer. It is designed to prevent the following deadlock. The receiver sends an acknowledgement with a window size of 0, telling the sender to wait.Later, the receiver updates the window, but the packet with the update is lost. Now both the sender and the receiver are waiting for each other to do something. When the persistence timer goes off, the sender transmits a probe to the receiver. The response to the probe gives the window size. If it is still zero, the persistence timer is set again and the cycle repeats. If it is nonzero, data can now be sent. A third timer that some implementations use is the keep alive timer. When a connection has been idle for a long time, the keep alive timer may go off to cause one side to check whether the other side is still here. If it fails to respond, the connection is terminated. This feature is controversial because it adds overhead and may terminate an otherwise healthy connection due to transient network partition. The last timer used on each TCP connection is the one used in the TIMED WAIT state while closing. It runs for twice the maximum packet lifetime to make sure that when a connection is closed; all packets created by it have died off.

No comments:

Post a Comment