You are here

TutorialLibraryTest ApplicationDownload
[Tutorial]LibraryTest ApplicationDownload

Socket Tutorial

Chapter 2 - Theory of Operations

Using sockets in connected mode

Behavior and use of sockets vary by protocol type. In connectionless mode (UDP style), the sequence of operations to be performed to send a data packet is relatively simple. Whoever wants to receive must create a socket bound to a port of the machine. Whoever wants to send data must know the IP address of its correspondent and port behind which a socket has been created.

However, the protocol simply sends the data packets to the requested address, without asking more questions. It is possible that a packet is lost during its travel, without the sender's knowledge.

The connection-oriented (TCP) mode, meanwhile, introduces the concept of reliable transportation. When a packet is sent from a correspondent A to correspondent B, this later sends back a little message to A saying that the packet has been received. On his side, A expects to receive this acknowledgement from B. If it is not received before a given deadline, the packet will be sent again, until is is finally acknowledged by B. After N unsuccessful attempts, A may decide that B no longer appears to be reachable at the end of the line and it closes the connection. The protocol also handles the case where multiple attempts to send the packet finally arrive at B. Indeed, B should only consider one of all the duplicated packets. All these mechanisms enable to know if the data were actually sent, or if a problem that requires to close the connection occurred.

This shows that this notion of connection is more symbolic than physical. It reflects the fact that 2 connected sockets manage counters, timers and acknowledgements in order to determine whether the physical link that connects them still allows to exchange data. Thus, even if the user does not receive or send a single message, the two sockets can continue to exchange small messages to prove to each other they are still alive. If they are not received, a timer will decide that the connection was interrupted.

A simple example of mechanisms implemented in the TCP/IP protocol is illustrated in the figure below. The first message M sent from A to B arrives safely, just as his acknowledgement. Message N is more problematic. It is first lost, B can not realize what is happening. After a while (timer expiration) A decides to send the message a second time, which this time is successful. However, the acknowledgement returned by B is slow to arrive (e.g. congested network). Finally, it comes after timer A expires again. Thus, A issues the same packet 3 times. B receive the duplicate a bit later and must ignore it since it corresponds to a message already received.

Setting up a connection first requires an establishment process (see figure below). This requires designating a server, i.e. one that will start listening on a port known to future clients (function bind and function listen). Clients can then connect to that port (function connect). If the server accepts the connection (depending on function accept), will follow an automatic exchange of messages that will establish the connection and determine the port used by the client for the communication. Indeed, the server needs to know the socket port number at the client side in order to communicate with it. The server port number remains the same that the one used for listening. The user cannot control the client port number negotiated during the connection. In fact, the machine chooses his own among those who are unused.

Finally, we end up with three sockets. The first was originally created by the user for listening while the other two are used for the new connection.