Unit 1 · Chapter 1 · Book pp. 3–30

Introduction

This chapter answers the only question that matters before any of the API makes sense: what is the thing we are programming? By the end of it you will have read a complete TCP client and a complete TCP server, line by line, and you will know where in the stack your code actually sits.

What network programming actually is

Every program you have written so far talked to things inside one machine — a file, a keyboard, a screen, some memory. Network programming is writing programs that talk to a process on a different machine, across a network you do not control, using rules both sides agreed on in advance.

What people actually build with it

• Exchange mail — Gmail, the college mail server.
• Move files between systems — upload and download, FTP, cloud sync.
• Share peripherals — a network printer, a shared drive.
• Run a program on another computer — every web API you have called.
• Log in remotely — SSH, remote desktop, working from home.

The client/server model

Almost every network application splits into two unequal halves. This asymmetry is the single most important idea in the chapter, and it is the reason the API has two different sets of functions.

Typical services a client asks for:

• Tell me the time of day.
• Print this file.
• Read or write a file on your system.
• Let me log in to your system.
• Run this command for me.

Two processes, four layers, one wire

The client and the server appear to talk to each other directly. They do not. Data goes down the protocol stack on one machine, across the physical network, and back up the stack on the other. Only the top layer — your program — gets the illusion of a direct line.

A first program: the daytime client

This is a complete, working TCP client in 27 lines. It connects to a daytime server — a standard service on port 13 that replies with the current date and time as human-readable text and then closes the connection. Step through it; the diagram underneath shows the connection coming into existence as you go.

Why this client is not good enough

The program above works only with IPv4, because AF_INET, struct sockaddr_in and inet_pton(AF_INET, …) are all hard-coded. Making it work with IPv6 means changing the structure, the family constant and the conversion call. The book calls the better answer protocol independence — writing clients and servers that do not name a protocol at all — and reaches it in Chapter 11 with getaddrinfo. §1.3 · p.10

Error handling: wrapper functions

Nearly every socket function can fail, and checking each one inflates every example by three lines. The book's solution is a wrapper function: the same call, capitalised, that checks the return value, prints a message and terminates on error.

int
Socket(int family, int type, int protocol)
{
    int   n;

    if ( (n = socket(family, type, protocol)) < 0)
        err_sys("socket error");
    return (n);
}

So Socket(AF_INET, SOCK_STREAM, 0) means exactly socket(AF_INET, SOCK_STREAM, 0) plus "and die if it fails". The convention throughout the book — and throughout this site — is:

A first server: the daytime server

Its counterpart, in 24 lines. Notice how different the shape is: the client is a straight line from top to bottom, while the server is a loop that never ends.

The OSI model, and where sockets sit

The OSI (Open Systems Interconnection) model was described by ISO to give a standard vocabulary for describing any network. It has seven layers. Its practical value here is that it tells you exactly which layer your program is, and which layers you are entitled to ignore.

What each layer actually does

Why layer at all

• Simplifies learning — a large problem is broken into smaller, manageable chunks.
• Reduces complexity — each layer solves one thing.
• Provides compatibility — standardised interfaces allow plug-and-play and multi-vendor integration.
• Facilitates modularisation — a new technology can be swapped in at one layer without disturbing the architecture.
• Accelerates evolution — developers work on one layer while changes are prevented from leaking into another.

Where the API came from

The sockets API originated in 4.2BSD, released in 1983, and spread from there into essentially every operating system. That history is why the API has some awkward corners — the sin_zero padding, the bzero/bcopy family, the word "socket" itself — that make no sense from first principles but plenty of sense as accumulated compatibility. §1.8 · p.20

Unix standards

Exam questions on this section are recall questions. Learn the names, the years and what each one added.

64-bit architectures

Through the 1990s Unix systems used the ILP32 model: integers, longs and pointers all 32 bits. The move to 64 bits chose LP64 — long and pointer become 64 bits, but int stays 32.