7 TCP

Typically, there are two types of applications that use TCP sockets - servers and clients. A TCP server listens on a well-known port (or IP address and port pair) and accepts connections from TCP clients. A TCP client initiates a connection request to a TCP server in order to setup a connection with the server. A real TCP server can accept multiple connections on a socket. A server socket in the simulator accepts only one TCP connection in its lifetime.

Below is the sequence of socket calls made by a TCP server and a TCP client:

Server: Socket -> Bind -> Accept -> Read/Write -> Close
Client: Socket -> (Bind) -> Connect -> Read/Write -> Close

Below are the details of the socket calls specification.

• A server must call Bind() in order to bind the socket to a port, before calling Accept(). Otherwise, Accept() returns an error. Bind() to a client socket is optional.

• We make the following changes to the Accept() specification:
  1. Accept() returns 0 on success (instead of a new file descriptor), and -1 on failure. Accept() does not create a new file descriptor (unlike the Berkeley Socket specification), and uses the same file descriptor for all subsequent socket calls.

  2. The socket starts accepting client connection requests only after the Accept() call has been made (i.e. packets arriving before the Accept() call are discarded).

  3. If during the connection establishment phase the protocol times out (e.g. during the TCP three-way handshake) or an error occurs, Accept() waits for other connection attempts, and returns only when a connection has been established successfully.
  4. Accept() is always blocking--Accept() should block until after a connection establishment is completed.

• Connect() is always blocking. It returns 0 if the connection establishment (TCP three-way handshake) succeeds, and returns -1 if an error occurs. One possible error is a timeout during the three-way handshake. In all cases where errors occur during the Connect() call, an application should not call Connect() again but should call Close() immediately.

• Read() is always blocking. On success, the number of bytes read is returned. If Read() returns 0, this indicates an ``End of File'', meaning that the other side has closed the connection, and no more data will be received by this socket.

• Write() returns almost immediately, except when the send buffer is full. This buffer is used by TCP to keep all data that could not be sent immediately (because of window limitations), as well as, data that has been sent but has not yet been acknowledged. If the send buffer is full, Write() blocks until the send buffer is freed to enqueue another packet.

• When a user program calls Close() on a TCP socket, the socket is marked as closed and the Close() function returns to the process immediately. The socket descriptor is no longer usable by the process, i.e. it would not be usable as an argument to Read() or Write(). TCP tries to send all data that is already queued to be sent to the other end, and after this occurs the normal TCP connection termination sequence takes place [1].