Socket API

Why it exists

An application on one computer must talk to an application on another, but the transport protocols live inside the operating system. The socket API (from the Berkeley UNIX of the early 1980s) is the interface through which programs ask the kernel for network communication: you create a socket, bind it to an address and port, connect or accept, and then send and receive almost as if you were writing to and reading from a file. It sits between the application layer and the transport layer (layering) and is implemented with system calls (system calls).

Prerequisites

You need TCP's connection and byte stream (TCP basics) and the idea of a system call (system calls).

Precise definitions

A socket is an endpoint of communication. A program creates one with socket(domain, type, protocol) and gets back a small integer, a descriptor, like a file descriptor. The type selects the transport service: SOCK_STREAM is TCP (reliable byte stream), SOCK_DGRAM is UDP (unreliable datagrams). The domain AF_INET means IPv4.

An endpoint address is the pair (IP address, port number) (struct sockaddr_in: family, 16-bit port in network byte order, 32-bit address).

The TCP server sequence (typical):

The TCP client sequence: socket(), connect(s, server address) (the kernel sends the SYN and returns when the handshake is complete or fails), then send()/recv(), then close(). The client normally does not call bind: the system chooses a free ephemeral port as the local port at connect.

The UDP sequence: socket(AF_INET, SOCK_DGRAM, 0); the receiver binds to a port; sendto(s, data, destination) and recvfrom(s, buf, ...). There is no listen, no accept, no connect and no handshake.

Two kinds of socket in a TCP server. The listening socket stays bound to the server's well-known port and only accepts connections. Each accepted connection has its own connected socket (a new descriptor) with the same local port and the client's address as the remote end. Connections are told apart by the four-tuple (source IP, source port, destination IP, destination port), so many clients can use one server port.

How it works

A TCP conversation, seen from the kernel

The table was produced by a real server and client on the loopback interface, reading the states of the TCP sockets with netstat after each step. Note that after connect() the connection is already ESTABLISHED although the server has not yet called accept(): the three-way handshake is handled by the kernel, and accept() merely hands the finished connection to the program. After the client closes, the client socket waits in FIN_WAIT_2 and the server's in CLOSE_WAIT until the server closes; the socket of the side that closed first ends in TIME_WAIT.

The C program

The program below does both the server and the client side in one process (possible because the connection is completed by the kernel before accept): it creates a listening socket on a port chosen by the system, connects to it, sends two pieces of data of $2$ and $3$ bytes, accepts, and receives them with a single call asking for $5$ bytes.

#include <arpa/inet.h>
#include <netinet/in.h>
#include <netinet/tcp.h>
#include <errno.h>
#include <stdio.h>
#include <string.h>
#include <sys/socket.h>
#include <unistd.h>
 
int main(void) {
    /* server side: socket, bind (port 0 = let the system choose), listen */
    int ls = socket(AF_INET, SOCK_STREAM, 0);
    struct sockaddr_in a;
    memset(&a, 0, sizeof a);
    a.sin_family = AF_INET;
    a.sin_addr.s_addr = htonl(INADDR_LOOPBACK);
    a.sin_port = 0;
    if (bind(ls, (struct sockaddr *)&a, sizeof a) < 0) return 1;
    if (listen(ls, 1) < 0) return 1;
    socklen_t len = sizeof a;
    getsockname(ls, (struct sockaddr *)&a, &len);
 
    /* client side: socket, connect; the handshake finishes in the kernel before accept is called */
    int c = socket(AF_INET, SOCK_STREAM, 0);
    int one = 1;
    setsockopt(c, IPPROTO_TCP, TCP_NODELAY, &one, sizeof one);
    if (connect(c, (struct sockaddr *)&a, sizeof a) < 0) return 1;
    send(c, "ab", 2, 0);
    send(c, "cde", 3, 0);
 
    int s = accept(ls, NULL, NULL);
    char buf[100];
    ssize_t n = recv(s, buf, 5, MSG_WAITALL); /* wait until 5 bytes have arrived */
    printf("two send calls (2 + 3 bytes), one recv for 5 bytes returned %zd bytes: %.*s\n", n, (int)n, buf);
 
    struct sockaddr_in cl, peer, srv;
    len = sizeof cl;
    getsockname(c, (struct sockaddr *)&cl, &len);
    len = sizeof peer;
    getpeername(s, (struct sockaddr *)&peer, &len);
    len = sizeof srv;
    getsockname(s, (struct sockaddr *)&srv, &len);
    printf("accepted socket's peer port == client's own port: %s\n", peer.sin_port == cl.sin_port ? "yes" : "no");
    printf("accepted socket's local port == listening port: %s\n", srv.sin_port == a.sin_port ? "yes" : "no");
    printf("accepted socket is a new descriptor: %s\n", s != ls ? "yes" : "no");
 
    /* a second bind to the port that is in use fails */
    int t = socket(AF_INET, SOCK_STREAM, 0);
    if (bind(t, (struct sockaddr *)&a, sizeof a) < 0) printf("second bind to the same port fails: %s\n", strerror(errno));
    close(t);
 
    /* closing one side: the other side's recv returns 0 (end of the stream) */
    close(c);
    n = recv(s, buf, sizeof buf, 0);
    printf("after the client closed, recv returned %zd\n", n);
    close(s);
    close(ls);
    return 0;
}

two send calls (2 + 3 bytes), one recv for 5 bytes returned 5 bytes: abcde
accepted socket's peer port == client's own port: yes
accepted socket's local port == listening port: yes
accepted socket is a new descriptor: yes
second bind to the same port fails: Address already in use
after the client closed, recv returned 0

The first line shows that TCP has no message boundaries: the two send calls were joined in the byte stream and one recv (with MSG_WAITALL, which waits for all $5$ bytes) returned both. Without MSG_WAITALL a recv returns whatever bytes are available at that moment: in an earlier trial one call returned only the first $2$ bytes and the next call the other $3$. A TCP program must therefore loop until it has read a complete message and must mark message ends itself (a length field, a delimiter, or closing the connection). The next lines show that the accepted socket is a new descriptor with the same local port as the listening socket, and that its remote port is the client's ephemeral port. A second bind to a port in use fails with the error "Address already in use". After the client closes, recv returns $0$.

UDP keeps the boundaries

#include <arpa/inet.h>
#include <netinet/in.h>
#include <stdio.h>
#include <string.h>
#include <sys/socket.h>
#include <unistd.h>
 
int main(void) {
    int r = socket(AF_INET, SOCK_DGRAM, 0);
    struct sockaddr_in a;
    memset(&a, 0, sizeof a);
    a.sin_family = AF_INET;
    a.sin_addr.s_addr = htonl(INADDR_LOOPBACK);
    a.sin_port = 0;
    if (bind(r, (struct sockaddr *)&a, sizeof a) < 0) return 1;
    socklen_t len = sizeof a;
    getsockname(r, (struct sockaddr *)&a, &len);
 
    int s = socket(AF_INET, SOCK_DGRAM, 0); /* no connect, no handshake */
    sendto(s, "ab", 2, 0, (struct sockaddr *)&a, sizeof a);
    sendto(s, "cde", 3, 0, (struct sockaddr *)&a, sizeof a);
 
    char buf[100];
    for (int i = 1; i <= 2; i++) {
        ssize_t n = recvfrom(r, buf, sizeof buf, 0, NULL, NULL);
        printf("recvfrom %d returned %zd bytes: %.*s\n", i, n, (int)n, buf);
    }
    close(s);
    close(r);
    return 0;
}

recvfrom 1 returned 2 bytes: ab
recvfrom 2 returned 3 bytes: cde

Each recvfrom returns exactly one datagram: the application sees the messages as they were sent (the two calls to sendto give two calls to recvfrom with $2$ and $3$ bytes). If the buffer is smaller than the datagram the excess is discarded. UDP does not guarantee delivery or order (on the loopback interface they are in practice never lost).

Worked examples

Cheat box

Traps and GATE patterns

Connections

The socket calls are system calls into the kernel's TCP and UDP code (system calls); what happens inside connect and close is the handshake and teardown of TCP basics. The application protocols that use sockets are HTTP over TCP and DNS over UDP.

PYQs

A TCP server application is programmed to listen
on port number P on host S. A TCP client is
connected to the TCP server over the network.
Consider that while the TCP connection was active,
the server machine S crashed and rebooted.
Assume that the client does not use the TCP
keepalive timer.

Which of the following behaviors is/are possible?

Consider socket API on a Linux machine that
supports connected UDP sockets. A connected UDP
socket is a UDP socket on which connect function has
already been called. Which of the following
statements is/are CORRECT?

I. A connected UDP socket can be used to
communicate with multiple peers simultaneously.
II. A process can successfully call connect function
again for an already connected UDP socket.

Identify the correct order in which a server process
must invoke the function calls accept, bind, listen, and
recv according to UNIX socket API.

Which one of the following socket API functions
converts an unconnected active TCP socket into a
passive socket?

A client process P needs to make a TCP connection
to a server process S. Consider the following
situation: the server process S executes a socket(),
a bind() and a listen() system call in that order,
following which it is preempted. Subsequently, the
client process P executes a socket() system call
followed by connect() system call to connect to the
server process S. The server process has not
executed any accept() system call. Which one of the
following events could take place?

Which of the following system calls results in the
sending of SYN packets?

Which one of the following is not a client-server
application?

Self-check

Revision card

References