Internals-1 2025, worked in full

2

The definition — that the length is a value going in and a result coming out, and why each.

2

Both directions named, with the 3 + 4 functions.

1

A code example showing sizeof(serv) against &len.

Answer

When a socket address structure is passed to any socket function it is always passed by reference — a pointer to the structure — and the length of the structure is passed as well. How the length is passed depends on the direction the structure is travelling.

Direction 1 — from the process to the kernel.

Three functions do this: bind, connect and sendto. One argument is the pointer to the socket address structure, and another is the integer size of the structure:

struct sockaddr_in  serv;

/* fill in serv{} */

connect(sockfd, (SA *) &serv, sizeof(serv));

Since the kernel is passed both the pointer and the size of what the pointer points to, it knows exactly how much data to copy from the process into the kernel. Here the size is a plain value argument — it goes in and nothing comes back.

Direction 2 — from the kernel to the process.

Four functions do this: accept, recvfrom, getsockname and getpeername. Here two of the arguments are the pointer to the socket address structure and a pointer to an integer containing the size:

struct sockaddr_un  cli;      /* Unix domain */
socklen_t  len;

len = sizeof(cli);             /* len is a value */

getpeername(unixfd, (SA *) &cli, &len);

/* len may have changed */

Worked example. A server accepting a connection:

struct sockaddr_storage  cli;
socklen_t  len;

len = sizeof(cli);             /* len = 128 going IN  */

connfd = accept(listenfd, (SA *) &cli, &len);

/* the peer was IPv4, so the kernel stored a 16-byte
   sockaddr_in and set len = 16 coming OUT.
   Had the peer been IPv6, len would now read 28. */

Going in, len = 128 is the limit: it stops the kernel overrunning the buffer. Coming out, len = 16 is the fact: it tells the process both how many bytes were written and, implicitly, what kind of peer connected.

The animated version of this figure →

The figure printed on the paper is UNP Figure 3.11, "Summary of address conversion functions" (book p.84), with the five function labels replaced by Function 1 to Function 5. It shows three numeric forms along the top and three presentation forms along the bottom.

3

Naming all five functions correctly.

1

Mapping each to its direction — presentation → numeric, or the reverse.

1

Saying which handle IPv6, and noting inet_addr is deprecated.

Answer — the five functions

Reading the figure column by column.

Reconstructed figure

This is the same figure, live. Press quiz me to blank the labels exactly as the exam paper did, and click any arrow for the prototype.

The prototypes, if asked

#include <arpa/inet.h>

int   inet_aton(const char *strptr, struct in_addr *addrptr);
in_addr_t inet_addr(const char *strptr);
char *inet_ntoa(struct in_addr inaddr);

int   inet_pton(int family, const char *strptr, void *addrptr);
const char *inet_ntop(int family, const void *addrptr,
                       char *strptr, size_t len);

1

Naming the command, with the -a flag.

3

All six column headers explained.

1

Reading the three rows — why the listening socket is still there and why the connection appears twice.

Part 1 — the command

netstat -a

netstat -a | grep 9877

netstat shows the status of the sockets on the system. The -a flag is essential: without it, listening sockets are not shown, and the third row — the LISTEN line — would be missing. That flag is worth stating explicitly.

The line Active Internet connections (servers and established) is netstat's own heading, and the word servers in it is confirmation that -a was used.

Part 2 — the column headers

Part 3 — reading the three rows

1

Stating the two categories: flag options and value options.

2

Correct level and category for all five.

2

A syntax line for each, with the right datatype — especially struct linger.

First, the two categories

Summary table

The syntax, one at a time

i. IP_TTL — level IPPROTO_IP, value option, int. Sets the default time-to-live (hop limit) in the IP header of outgoing unicast packets. Default 64 for TCP and UDP, 255 for raw sockets.

int  ttl = 64;
socklen_t  len = sizeof(ttl);

setsockopt(sockfd, IPPROTO_IP, IP_TTL, &ttl, sizeof(ttl));
getsockopt(sockfd, IPPROTO_IP, IP_TTL, &ttl, &len);

ii. SO_BROADCAST — level SOL_SOCKET, flag option, int. Permits the sending of broadcast datagrams. Applies only to datagram sockets; broadcasting is not supported on a stream socket.

int  on = 1;
socklen_t  len = sizeof(on);

setsockopt(sockfd, SOL_SOCKET, SO_BROADCAST, &on, sizeof(on));
getsockopt(sockfd, SOL_SOCKET, SO_BROADCAST, &on, &len);

iii. TCP_MAXSEG — level IPPROTO_TCP, value option, int. Fetches or sets the maximum segment size — the maximum amount of TCP data sent per segment. The value is the one announced in the MSS option on the SYNs, so fetching it on an established connection returns what the peer announced.

int  mss;
socklen_t  len = sizeof(mss);

getsockopt(sockfd, IPPROTO_TCP, TCP_MAXSEG, &mss, &len);
setsockopt(sockfd, IPPROTO_TCP, TCP_MAXSEG, &mss, sizeof(mss));

iv. IPV6_DONTFRAG — level IPPROTO_IPV6, flag option, int. Disables automatic fragmentation for datagram or raw sockets: an oversized packet is dropped rather than fragmented, and no error is returned to the process.

int  on = 1;
socklen_t  len = sizeof(on);

setsockopt(sockfd, IPPROTO_IPV6, IPV6_DONTFRAG, &on, sizeof(on));
getsockopt(sockfd, IPPROTO_IPV6, IPV6_DONTFRAG, &on, &len);

v. SO_LINGER — level SOL_SOCKET, value option, and the only one of the five that takes a structure. It specifies how close operates for a connection-oriented protocol.

struct linger {
    int  l_onoff;    /* 0 = off, nonzero = on */
    int  l_linger;   /* linger time, in seconds */
};

struct linger  ling;
socklen_t  len = sizeof(ling);

ling.l_onoff  = 1;
ling.l_linger = 30;

setsockopt(sockfd, SOL_SOCKET, SO_LINGER, &ling, sizeof(ling));
getsockopt(sockfd, SOL_SOCKET, SO_LINGER, &ling, &len);

Its three behaviours:

• l_onoff = 0 — the default. close returns immediately; remaining data is delivered in the background.
• l_onoff non-zero, l_linger = 0 — abortive close. TCP discards remaining data and sends an RST, skipping the four-packet termination and TIME_WAIT.
• l_onoff non-zero, l_linger non-zero — the process sleeps until all data is sent and acknowledged, or the linger time expires (in which case close returns EWOULDBLOCK and remaining data is discarded).

2

What an association is, and why SCTP says "association" rather than "connection".

3

The four-way handshake diagram, correctly labelled.

2

The five numbered establishment steps, with the cookie explained.

2

The three-way shutdown diagram and steps.

1

The differences from TCP — no half-close, no TIME_WAIT.

1 · What an association is

SCTP provides associations between clients and servers. Like TCP it provides reliability, sequencing, flow control and full-duplex data transfer, and like TCP it is connection-oriented, so it has establishment and termination handshakes.

The word association is used instead of connection deliberately. A connection is between two IP addresses. An association is between two endpoints, each of which may have several IP addresses — SCTP supports multihoming — so "connection" would be too narrow a word. SCTP is also message-oriented, providing sequenced delivery of individual records, and provides multiple streams within one association, so a loss in one stream does not block delivery in the others.

2 · Association establishment — the four-way handshake

1. The server must be prepared to accept an incoming association. This is normally done by calling socket, bind and listen, and is called a passive open.
2. The client issues an active open by calling connect, or by sending a message which implicitly opens the association. This causes the client SCTP to send an INIT message, telling the server:
   • the client's list of IP addresses,
   • its initial sequence number,
   • an initiation tag to identify all packets in this association,
   • the number of outbound streams the client is requesting,
   • the number of inbound streams the client can support.
3. The server acknowledges the client's INIT with an INIT-ACK message, containing the server's list of IP addresses, initial sequence number, initiation tag, outbound and inbound stream counts, and a state cookie. The state cookie contains all of the state the server needs to ensure that the association is valid, and is digitally signed to ensure its validity.
4. The client echoes the server's state cookie back in a COOKIE-ECHO message. This message may also contain user data bundled within the same packet.
5. The server acknowledges that the cookie was correct and that the association was established, with a COOKIE-ACK message. This message may also contain user data.

The minimum number of packets required for this exchange is four; hence this process is called SCTP's four-way handshake.

3 · The tags and the cookie

The INIT carries a verification tag Ta and an initial sequence number J. Ta must be present in every packet sent by the peer for the life of the association. The peer chooses its own verification tag Tz, which must be present in each of its packets. J is the starting sequence number for DATA messages, which SCTP calls DATA chunks. The receiver of the INIT also sends a cookie C, which contains all the state needed to set up the association so that the server's SCTP stack does not need to keep information about the associating client. At the conclusion of the handshake each side chooses a primary destination address, used as the default destination in the absence of network failure.

4 · Association termination — the three-way shutdown

Unlike TCP, SCTP does not support a half-close. When one end shuts down an association, the other end must stop sending new data, and any data queued at either end is still transmitted before the shutdown completes — so no queued data is lost.

1. One end calls close; its SCTP sends a SHUTDOWN chunk.
2. The peer drains its queues and replies with a SHUTDOWN-ACK chunk.
3. The initiator responds with SHUTDOWN-COMPLETE, and the association is gone.

Three packets, and SCTP has no TIME_WAIT state — the verification tags already prevent an old packet being mistaken for part of a new association, which is exactly the job TIME_WAIT does for TCP.

5 · Comparison with TCP — the closing paragraph

4

The diagram: eleven states, correctly placed and correctly named.

2

Arrows labelled with both the trigger (appl: / recv:) and what is sent.

2

The normal client path and the normal server path marked.

2

The explanation — the two exits from ESTABLISHED, and TIME_WAIT.

The diagram

Click any state to isolate its transitions, or use the walk buttons to trace the normal client and server paths — those are the two you must mark on your own drawing.

The explanation

The operation of TCP with regard to connection establishment and termination can be specified with a state transition diagram. There are 11 states defined for a connection, and the rules of TCP dictate the transitions from one to another based on the current state and the segment received in that state.

For example: if an application performs an active open in the CLOSED state, TCP sends a SYN and the new state is SYN_SENT. If TCP next receives a SYN with an ACK, it sends an ACK and the new state is ESTABLISHED. This final state is where most data transfer occurs.

The two arrows out of ESTABLISHED

The two normal paths

The book denotes the normal client transitions with a darker solid line and the normal server transitions with a darker dashed line. Mark yours the same way — the question says "explain the same", and marking the two normal paths is how you show which of the nineteen transitions actually happen in practice.

Reading the labels, and the two rare transitions

• appl: — the transition is taken because the application issued an operation.
• recv: — the transition is taken because a segment was received.
• send: — what TCP sends for this transition.

Two transitions are possible but rare: a simultaneous open, when both ends send SYNs at about the same time and the SYNs cross in the network, and a simultaneous close, when both ends send FINs at the same time. The CLOSING state exists only for the second of these.

Why the diagram matters practically

One reason for showing it is to give the 11 TCP states with their names, because those names are exactly what netstat displays — which makes it the tool for debugging client/server applications. See Q2(b).

Finally, the end that performs the active close goes through TIME_WAIT, and stays there for 2MSL. There are two reasons for that state: (1) to implement TCP's full-duplex connection termination reliably — if the final ACK is lost, this end must retain enough state to resend it, or it would answer the retransmitted FIN with an RST; and (2) to allow old duplicate segments to expire in the network, so an old duplicate cannot be delivered to a new incarnation of the same socket pair.

5

Part (i) — the union, the test, and an explanation of why a union works.

5

Part (ii) — the full server, with accept taking a real address, inet_ntop and ntohs.

Part (i) — byteorder.c

#include	"unp.h"

int
main(int argc, char **argv)
{
    union {
        short  s;
        char   c[sizeof(short)];
    } un;

    un.s = 0x0102;
    printf("%s: ", CPU_VENDOR_OS);

    if (sizeof(short) == 2) {
        if (un.c[0] == 1 && un.c[1] == 2)
            printf("big-endian\n");
        else if (un.c[0] == 2 && un.c[1] == 1)
            printf("little-endian\n");
        else
            printf("unknown\n");
    } else
        printf("sizeof(short) = %d\n", sizeof(short));

    exit(0);
}

How it works — write this next to the code

1. A union stores all of its members at the same memory address. So un.s and un.c are two different ways of looking at the same two bytes: one as a 16-bit integer, one as an array of individual bytes.
2. un.s = 0x0102 stores a value whose high-order byte is 0x01 and whose low-order byte is 0x02. The two bytes are deliberately different so they can be told apart — which is why 0x0102 and not, say, 0x0101.
3. Reading un.c[0] reads the byte at the starting address. So:
   • c[0] == 1 means the high-order byte is stored first → big-endian.
   • c[0] == 2 means the low-order byte is stored first → little-endian.
4. The sizeof(short) == 2 guard exists because the whole test assumes a two-byte short. If the compiler used a different size the program says so rather than printing a wrong answer.
5. CPU_VENDOR_OS is a string constant determined by the book's configure script, so the output identifies which machine produced it.

Change the value below to see the same union viewed both ways:

Part (ii) — Daytime server printing the client's IP and port

This is the Chapter 1 daytime server with one change: accept is given a real socket address structure instead of NULL, and the result is converted for printing.

#include	"unp.h"
#include	<time.h>

int
main(int argc, char **argv)
{
    int     listenfd, connfd;
    socklen_t len;
    struct sockaddr_in servaddr, cliaddr;
    char    buff[MAXLINE];
    time_t  ticks;

    listenfd = Socket(AF_INET, SOCK_STREAM, 0);

    bzero(&servaddr, sizeof(servaddr));
    servaddr.sin_family      = AF_INET;
    servaddr.sin_addr.s_addr = htonl(INADDR_ANY);
    servaddr.sin_port        = htons(13);    /* daytime server */

    Bind(listenfd, (SA *) &servaddr, sizeof(servaddr));

    Listen(listenfd, LISTENQ);

    for ( ; ; ) {
        len = sizeof(cliaddr);              /* value-result: reset every time */
        connfd = Accept(listenfd, (SA *) &cliaddr, &len);

        printf("connection from %s, port %d\n",
               Inet_ntop(AF_INET, &cliaddr.sin_addr, buff, sizeof(buff)),
               ntohs(cliaddr.sin_port));

        ticks = time(NULL);
        snprintf(buff, sizeof(buff), "%.24s\r\n", ctime(&ticks));
        Write(connfd, buff, strlen(buff));

        Close(connfd);
    }
}

The four things to point out

4

The server: socket, bind, listen, accept, fork, and both closes.

3

The service function that computes and returns the length.

2

The client: socket, connect, write, read.

1

Output, and a note on why the newline is stripped.

Server — strlenserv.c

#include	"unp.h"

void	str_len(int sockfd);

int
main(int argc, char **argv)
{
    int     listenfd, connfd;
    pid_t   childpid;
    socklen_t clilen;
    struct sockaddr_in cliaddr, servaddr;

    listenfd = Socket(AF_INET, SOCK_STREAM, 0);

    bzero(&servaddr, sizeof(servaddr));
    servaddr.sin_family      = AF_INET;
    servaddr.sin_addr.s_addr = htonl(INADDR_ANY);
    servaddr.sin_port        = htons(SERV_PORT);   /* 9877 */

    Bind(listenfd, (SA *) &servaddr, sizeof(servaddr));
    Listen(listenfd, LISTENQ);

    for ( ; ; ) {
        clilen = sizeof(cliaddr);
        connfd = Accept(listenfd, (SA *) &cliaddr, &clilen);

        if ( (childpid = Fork()) == 0) {    /* child process */
            Close(listenfd);                /* child closes listening socket */
            str_len(connfd);                /* serve this client       */
            exit(0);
        }
        Close(connfd);                      /* parent closes connected socket */
    }
}

/* read a line, send back its length */
void
str_len(int sockfd)
{
    ssize_t  n;
    char     line[MAXLINE], reply[MAXLINE];

    for ( ; ; ) {
        if ( (n = Readline(sockfd, line, MAXLINE)) == 0)
            return;                   /* client closed the connection */

        line[strcspn(line, "\r\n")] = '\0';   /* strip the terminator */

        snprintf(reply, sizeof(reply), "%d\n", (int) strlen(line));
        Writen(sockfd, reply, strlen(reply));
    }
}

Client — strlencli.c

#include	"unp.h"

void	str_lencli(FILE *fp, int sockfd);

int
main(int argc, char **argv)
{
    int     sockfd;
    struct sockaddr_in servaddr;

    if (argc != 2)
        err_quit("usage: strlencli <IPaddress>");

    sockfd = Socket(AF_INET, SOCK_STREAM, 0);

    bzero(&servaddr, sizeof(servaddr));
    servaddr.sin_family = AF_INET;
    servaddr.sin_port   = htons(SERV_PORT);
    Inet_pton(AF_INET, argv[1], &servaddr.sin_addr);

    Connect(sockfd, (SA *) &servaddr, sizeof(servaddr));

    str_lencli(stdin, sockfd);          /* do it all */

    exit(0);
}

void
str_lencli(FILE *fp, int sockfd)
{
    char  sendline[MAXLINE], recvline[MAXLINE];

    while (Fgets(sendline, MAXLINE, fp) != NULL) {

        Writen(sockfd, sendline, strlen(sendline));

        if (Readline(sockfd, recvline, MAXLINE) == 0)
            err_quit("str_lencli: server terminated prematurely");

        Fputs(recvline, stdout);
    }
}

The five points to explain