Understanding TCP Protocol for Reliable Data Transmission

CHAPTER 3 : TCP TCP Protocole In contrast to a simple demultiplexing protocol like UDP, a more sophisticated transport protocol is one that offers a reliable, connection oriented, byte-stream service. Such a service has proven useful to a wide assortment of applications because it frees the application from having to worry about missing or reordered data. The Internet s Transmission Control Protocol is probably the most widely used protocol of this type; it is also the most carefully tuned. Protocols that carry documents and files nearly always ride atop TCP. This includes the delivery of web pages to your browser, file transmission, and all of the major mechanisms for transmitting e-mail. TCP is also the foundation of choice for protocols that carry on long conversations between people or computers, such as SSH terminal sessions and many popular chat protocols.

CHAPTER 3 : TCP TCP Protocole TCP guarantees the reliable, in-order delivery of a stream of bytes. It is a full-duplex protocol, meaning that each TCP connection supports a pair of byte streams, one flowing in each direction. Unless a connection dies or freezes because of a network problem, TCP guarantees that the data stream will arrive intact, without any information lost, duplicated, or out of order. It also includes a flow control mechanism for each of these byte streams that allows the receiver to limit how many data bytes the sender can transmit at a given time. Like UDP, TCP supports a demultiplexing mechanism that allows multiple application programs on any given host to simultaneously carry on a conversation with their peers.

CHAPTER 3 : TCP TCP Protocole How does TCP provide a reliable connection? Here are its basic tenets: Every TCP packet is given a sequence number so that the system on the receiving end can put them back together in the right order and can also notice missing packets in the sequence and ask that they be retransmitted. Instead of using sequential integers (1, 2, 3...) to sequence packets, TCP uses a counter that counts the number of bytes transmitted. A 1,024-byte packet with a sequence number of 7,200, for example, would be followed by a packet with a sequence number of 8,224. This means that a busy network stack does not have to remember how it broke up a data stream into packets. If asked for a retransmission, it can break up the stream into new packets some other way (which might let it fit more data into a packet if more bytes are now waiting for transmission), and the receiver can still put the packets back together.

CHAPTER 3 : TCP TCP Protocole The initial sequence number, in good TCP implementations, is chosen randomly so that villains cannot assume that every connection starts at byte zero. Predictable sequence numbers unfortunately make it easier to craft forged packets that might interrupt a conversation by looking like they are a legitimate part of its data. Rather than running very slowly in lock step by needing every packet to be acknowledged before it sends the next one, TCP sends whole bursts of packets at a time before expecting a response. The amount of data that a sender is willing to have on the wire at any given moment is called the size of the TCP window. The TCP implementation on the receiving end can regulate the window size of the transmitting end and thus slow or pause the connection. This is called flow control. This lets a receiver forbid the transmission of additional packets in cases where its input buffer is full, and it would have to discard more data anyway even if it were to arrive.

CHAPTER 3 : TCP TCP Protocole Finally, if TCP believes that packets are being dropped, it assumes that the network is becoming congested and reduces how much data it sends every second. This can be something of a disaster on wireless networks and other media where packets are lost simply because of noise. It can also ruin connections that are running fine until a router reboots and the endpoints cannot talk for, say, 20 seconds. By the time the network comes back up, the two TCP peers will have decided that the network is extraordinarily overloaded with traffic, and upon reestablishing contact, they will at first refuse to send each other data at anything other than a trickle.

CHAPTER 3 : TCP TCP Protocole Instances in which its TCP behavior is not optimal! First, TCP is unwieldy for protocols where clients want to send single, small requests to a server, and then they are done and will not talk to it further. It takes three packets for two hosts to set up a TCP connection the famous sequence of SYN, SYN-ACK, and ACK. SYN: I want to talk; here is the packet sequence number I will be starting with. SYN-ACK: Okay, here is the initial sequence number I will be using in my direction. ACK: Okay! Another three or four packets are necessary to shut the connection down when it is finished either a quick FIN, FIN-ACK, and ACK, or else a slightly longer pair of separate FIN and ACK packets in each direction.

CHAPTER 3 : TCP TCP Protocole The second situation where TCP is inappropriate is when an application can do something much smarter than simply retransmit data when a packet has been lost. Imagine an audio chat conversation, for example. If a second s worth of data is lost because of a dropped packet, then it will do little good simply to resend that same second of audio, over and over, until it finally arrives. Instead, the client should just fill that awkward second with whatever audio it can piece together from the packets that did arrive (a clever audio protocol will begin and end each packet with a bit of heavily compressed audio from the preceding and following moments of time to cover exactly this situation) and then keep going after the interruption as though it did not occur. This is impossible with TCP, which will keep stubbornly retransmitting the lost information even when it is far too old to be of any use. UDP datagrams are often the foundation of live-streaming multimedia over the Internet.

CHAPTER 3 : TCP Socket-based communication Sockets are the endpoints of a connection between host machines and can be used to send and receive data. TCP actually involves two completely different kinds of sockets: passive listening sockets and active connected ones. The passive socket or listening socket maintains the socket name the address and port number at which the server is ready to receive connections. No data can ever be received or sent by this kind of socket. It does not represent any actual network conversation. Instead, it is how the server alerts the operating system to its willingness to receive incoming connections at a given TCP port number in the first place.

CHAPTER 3 : TCP Socket-based communication An active, connected socket is bound to one particular remote conversation partner with a particular IP address and port number. It can be used only for talking back and forth with that one partner, and it can be read and written to without worrying about how the resulting data will be split up into packets. The stream looks so much like a pipe or file that, on Unix systems, a connected TCP socket can be passed to another program that expects to read from a normal file, and that program will never even know that it is talking over the network.

CHAPTER 3 : TCP Socket based communication Serveur The server begins by creating a ServerSocket to receive connection requests ServerSocket(port) S e r v e r A p p l i c a t i o n ServerSocket: ss Client Client Application

CHAPTER 3 : TCP Socket based communication Serveur The server waits connection requests S e r v e r A p p l i c a t i o n ServerSocket: ss ss.accept() Client Client Application

CHAPTER 3 : TCP Socket based communication The client requests a connection through the port associated with the service Serveur S e r v e r A p p l i c a t i o n Socket( Serveur , port) ServerSocket: ss ss.accept() Client Client Application

CHAPTER 3 : TCP Socket based communication The server creates a new socket which will be one of the two endpoints of the connection Serveur S e r v e r A p p l i c a t i o n ServerSocket: ss Socket( Serveur , port) ss.accept() Client Client Application Socket: s

CHAPTER 3 : TCP Socket based communication Serveur The client obtains the socket, which is thesecond endpoint of the connection S e r v e r A p p l i c a t i o n ServerSocket: ss ss.accept() Client Client Application Socket: s Socket: s

CHAPTER 3 : TCP Socket based communication Serveur The client and server create the associated InputStream and OutputStream (to the two sockets) S e r v e r A p p l i c a t i o n ServerSocket: ss ss.accept() Client Application Client Socket: s is os Socket: s is os s.getInputStream s.getInputStream s.getOutputStream s.getOutputStream

CHAPTER 3 : TCP Socket based communication Serveur Client and server begin data data exchanges via the corresponding sockets (InputStream and OutputStream) S e r v e r A p p l i c a t i o n ServerSocket: ss ss.accept() Client is.read() Client Application Socket: s is os Socket: s is os os.write(int nb) is.read() os.write(int nb)

CHAPTER 3 : TCP Server Socket in Java A server socket is an instance of the ServerSocket class and can be created using one of these constructors: ServerSocket(int port) ServerSocket(int port, int backlog) port : port number on which the server will listen for client requests. backlog : maximum length of client queue waiting to be served (50 by default).

CHAPTER 3 : TCP Server Socket methods in Java Socket accept() Waits for a connection request. The thread executing the method will be blocked until a request is received, at which point the method returns a client socket. void close() Stop waiting for client requests!

CHAPTER 3 : TCP Typical usage of ServerSocket try { ServerSocket s = new ServerSocket(port); while (true) { Socket incoming = s.accept(); Traite un client incoming.close(); } s.close(); } catch (IOException e) { Traite l exception }

CHAPTER 3 : TCP Client Socket A client socket is an instance of the Socket class and can be obtained in two ways: 1) on the server side, as a value returned by the accept() method 2) on the client side, using the constructor Socket(String host, int port) host: host machine address port: port number

CHAPTER 3 : TCP Client Socket Methods getInputStream() Returns an InputStream object receiving data getOutputStream() Returns an OutputStream object to send data close() Closes the socket connection

CHAPTER 3 : TCP Typical usage of Client Socket try { Socket socket = new Socket(host, port); BufferedReader in = new BufferedReader( new InputStreamReader(socket.getInputStream())); PrintWriter out = new PrintWriter( new OutputStreamWriter(socket.getOutputStream()));! Send and Receive Data in.close(); out.close(); socket.close();} catch (IOException e) { Traite l exception }