Client/Server Sockets — Sockets | OneNoughtOne

0/121

Computer NetworksTransport Layer Concepts

Sockets

LevelIntermediate

Duration60 mins

TopicTransport Layer Concepts

4 / 5

Client/Server Sockets

Architectural Patterns for Network Applications

The socket API provides primitives; building applications requires patterns . The most fundamental pattern in network programming is the client/server model, where server processes wait for connection requests and client processes initiate contact. This seemingly simple model has profound architectural implications. How does a server handle multiple clients? Should it dedicate a thread per connection or use event-driven I/O? How do clients handle slow or unresponsive servers? These questions have shaped decades of software architecture, from Apache's prefork model to NGINX's event-driven design to modern async/await patterns. Mastering client/server socket programming means understanding not just the code, but the architectural tradeoffs that determine scalability, latency, and resource utilization.

What You Will Learn

By the end of this page, you will understand the client and server socket lifecycles, iterative and concurrent server models, the roles of listening and connected sockets, and how to design for scalability. You'll be equipped to architect network services for any scale.

The Client/Server Model

The client/server model is an asymmetric communication pattern where: Server: Waits passively for connections (listening) Runs continuously (daemon/service) Serves multiple clients simultaneously or sequentially Has a well-known address (fixed IP/port) Typically provides a specific service (HTTP, database, email) Client: Initiates connections actively Runs when needed, terminates when done Connects to one or more servers Uses ephemeral local ports Requests services from servers This model decouples service providers from consumers, enabling the distributed systems architecture that powers the modern internet.

Converting Mermaid diagram...

Socket Lifecycle Comparison:

Server vs. Client Socket Lifecycle
Phase	Server	Client
Creation	socket()	socket()
Address Assignment	bind() to known port	Automatic or bind() to ephemeral
Role Designation	listen() → passive mode	—
Connection Phase	accept() → blocks/waits	connect() → initiates
Data Transfer	recv()/send() on accepted socket	recv()/send() on connected socket
Termination	close() client socket; keep listening	close() socket
Lifespan	Long-running (daemon)	Short-lived (session)

The Two Server Sockets

A key insight: servers have TWO types of sockets. The LISTENING socket (created once, used for accept()) and CONNECTED sockets (one per client, used for data transfer). The listening socket never sends or receives application data—it only exists to accept new connections.

Client Implementation Patterns

Client sockets follow a straightforward pattern: connect, communicate, disconnect. However, production clients require careful error handling, timeout management, and connection reuse. Basic Client Pattern: 1. Create socket: socket() 2. Connect to server: connect() 3. Send request: send() 4. Receive response: recv() (loop until complete) 5. Close connection: close()

client_patterns.c
C
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
#include <sys/socket.h>
#include <netdb.h>
#include <string.h>
#include <stdio.h>
#include <unistd.h>
#include <errno.h>
 
// Production-quality TCP client
typedef struct {
    int sockfd;
    char host[256];
    char port[16];
    int connected;
} Client;
 
int client_connect(Client *c, const char *host, const char *port) {
    struct addrinfo hints = {0}, *res, *p;
    hints.ai_family = AF_UNSPEC;     // IPv4 or IPv6
    hints.ai_socktype = SOCK_STREAM; // TCP
    
    int err = getaddrinfo(host, port, &hints, &res);
    if (err != 0) {
        fprintf(stderr, "Resolution failed: %s
", gai_strerror(err));
        return -1;
    }
    
    // Try each resolved address
    for (p = res; p != NULL; p = p->ai_next) {
        c->sockfd = socket(p->ai_family, p->ai_socktype, p->ai_protocol);
        if (c->sockfd == -1) continue;
        
        if (connect(c->sockfd, p->ai_addr, p->ai_addrlen) == 0) {
            break;  // Success
        }
        
        close(c->sockfd);
        c->sockfd = -1;
    }
    
    freeaddrinfo(res);
    
    if (p == NULL) {
        fprintf(stderr, "Failed to connect to %s:%s
", host, port);
        return -1;
    }
    
    strncpy(c->host, host, sizeof(c->host) - 1);
    strncpy(c->port, port, sizeof(c->port) - 1);
    c->connected = 1;
    
    return 0;
}
 
ssize_t client_send(Client *c, const void *data, size_t len) {
    if (!c->connected) return -1;
    
    size_t sent = 0;
    while (sent < len) {
        ssize_t n = send(c->sockfd, (char*)data + sent, len - sent, 
                        MSG_NOSIGNAL);
        if (n == -1) {
            if (errno == EINTR) continue;
            c->connected = 0;
            return -1;
        }
        sent += n;
    }
    return sent;
}
 
ssize_t client_recv(Client *c, void *buf, size_t len) {
    if (!c->connected) return -1;
    
    ssize_t n = recv(c->sockfd, buf, len, 0);
    if (n <= 0) {
        c->connected = 0;
    }
    return n;
}
 
void client_close(Client *c) {
    if (c->sockfd >= 0) {
        close(c->sockfd);
        c->sockfd = -1;
    }
    c->connected = 0;
}
 
// Example usage: simple HTTP request
void example_http_request() {
    Client c = {.sockfd = -1};
    
    if (client_connect(&c, "example.com", "80") != 0) {
        return;
    }
    
    const char *request = "GET / HTTP/1.1\r
"
                          "Host: example.com\r
"
                          "Connection: close\r
"
                          "\r
";
    
    client_send(&c, request, strlen(request));
    
    char buf[4096];
    ssize_t n;
    while ((n = client_recv(&c, buf, sizeof(buf) - 1)) > 0) {
        buf[n] = '\0';
        printf("%s", buf);
    }
    
    client_close(&c);
}

Client Best Practices

•Use getaddrinfo() — Support both IPv4 and IPv6 transparently. Try all returned addresses for redundancy.
•Implement connection timeouts — Non-blocking connect with select/poll prevents hanging on unreachable servers.
•Handle partial sends/receives — Loop until all data is transferred; never assume single-call completion.
•Implement reconnection logic — Network connections fail; clients should retry with exponential backoff.
•Use connection pooling — Reusing connections amortizes TCP handshake overhead for repeated requests.
•Set appropriate socket options — TCP_NODELAY for latency-sensitive apps; appropriate buffer sizes for throughput.

The Slow Server Problem

A blocking client hangs indefinitely if the server stops responding. Production clients must implement timeouts using: (1) non-blocking sockets with select/poll/epoll, (2) SO_RCVTIMEO/SO_SNDTIMEO socket options, or (3) application-level timer threads. No network call should block indefinitely.

Iterative Server Model

The simplest server model handles one client at a time: accept a connection, process the entire request, close the connection, then accept the next. This is the iterative server . Characteristics: Single-threaded, single-process Clients are served sequentially Simple to implement and debug No concurrency complexity Limitations: Subsequent clients blocked during processing Poor utilization of multi-core systems Unsuitable for long-running requests No fault isolation between requests

iterative_server.c
C
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
#include <sys/socket.h>
#include <netinet/in.h>
#include <string.h>
#include <stdio.h>
#include <unistd.h>
#include <signal.h>
 
static volatile int running = 1;
 
void handle_sigint(int sig) {
    running = 0;
}
 
// Handle a single client connection
void handle_client(int client_fd) {
    char buf[4096];
    ssize_t n;
    
    // Simple echo server: read and echo back
    while ((n = recv(client_fd, buf, sizeof(buf), 0)) > 0) {
        // Echo the data back
        ssize_t sent = 0;
        while (sent < n) {
            ssize_t s = send(client_fd, buf + sent, n - sent, MSG_NOSIGNAL);
            if (s <= 0) return;  // Error or closed
            sent += s;
        }
    }
}
 
// Iterative server main loop
int run_iterative_server(uint16_t port) {
    signal(SIGINT, handle_sigint);
    signal(SIGPIPE, SIG_IGN);  // Ignore broken pipe
    
    // Create listening socket
    int listen_fd = socket(AF_INET, SOCK_STREAM, 0);
    if (listen_fd == -1) {
        perror("socket");
        return -1;
    }
    
    // Allow address reuse
    int opt = 1;
    setsockopt(listen_fd, SOL_SOCKET, SO_REUSEADDR, &opt, sizeof(opt));
    
    // Bind
    struct sockaddr_in addr = {0};
    addr.sin_family = AF_INET;
    addr.sin_addr.s_addr = htonl(INADDR_ANY);
    addr.sin_port = htons(port);
    
    if (bind(listen_fd, (struct sockaddr*)&addr, sizeof(addr)) == -1) {
        perror("bind");
        close(listen_fd);
        return -1;
    }
    
    // Listen
    if (listen(listen_fd, 128) == -1) {
        perror("listen");
        close(listen_fd);
        return -1;
    }
    
    printf("Iterative server listening on port %d
", port);
    
    // Main loop: accept and handle one at a time
    while (running) {
        struct sockaddr_in client_addr;
        socklen_t addr_len = sizeof(client_addr);
        
        int client_fd = accept(listen_fd, 
                               (struct sockaddr*)&client_addr, 
                               &addr_len);
        
        if (client_fd == -1) {
            if (errno == EINTR) continue;  // Interrupted, retry
            perror("accept");
            continue;
        }
        
        printf("Client connected (fd=%d)
", client_fd);
        
        // Handle this client completely before accepting another
        handle_client(client_fd);
        
        printf("Client disconnected (fd=%d)
", client_fd);
        close(client_fd);
    }
    
    close(listen_fd);
    printf("Server shutdown
");
    return 0;
}

When to Use Iterative Servers:

Scenario	Suitable?	Reason
Simple echo server	✓	Fast processing, no blocking
DNS server (simple)	✓	Quick queries, stateless
High-traffic web server	✗	Clients queue behind slow requests
Database server	✗	Queries may take seconds
Development/testing	✓	Easy debugging, reproducible behavior
Embedded systems	✓	Minimal resource usage

The Head-of-Line Blocking Problem

In iterative servers, a single slow client blocks all others. If Client A sends a request that takes 10 seconds to process, Clients B, C, D must all wait—even if their requests would complete in milliseconds. This head-of-line blocking is the fundamental limitation that motivates concurrent server designs.

Concurrent Server Models

To handle multiple clients simultaneously, servers employ concurrency. Several models exist, each with distinct tradeoffs: 1. Process-Per-Connection (fork): fork() after accept() creates child process for each client Complete memory isolation between clients High overhead (memory, context switches) Used by: Early Apache, PostgreSQL 2. Thread-Per-Connection: pthread_create() after accept() creates thread for each client Shared memory between threads (faster IPC) Lower overhead than processes, still significant Used by: Many traditional servers 3. Thread Pool: Pre-created pool of worker threads Accept in main thread, dispatch to idle worker Bounds resource usage, reduces thread creation overhead Used by: Tomcat, many database servers 4. Event-Driven (Single-Threaded): One thread handles all connections using I/O multiplexing Non-blocking I/O with select/poll/epoll No concurrency overhead, but complex state management Used by: NGINX, Node.js, Redis 5. Hybrid (Event-Driven + Thread Pool): Event loop accepts and manages I/O Thread pool for blocking/CPU-intensive operations Best of both worlds for many workloads Used by: Modern servers

Concurrent Server Model Comparison
Model	Connections	Memory	Latency	Complexity
Iterative	1 (blocking)	Minimal	High for waiting clients	Simple
Fork per connection	~1,000	High (per-process)	Good	Simple
Thread per connection	~10,000	Moderate (per-thread)	Good	Moderate
Thread pool	~10,000	Bounded	Good	Moderate
Event-driven	~100,000+	Minimal	Excellent	Complex
Hybrid	~100,000+	Bounded	Excellent	Complex

concurrent_models.c
C
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
#include <sys/socket.h>
#include <pthread.h>
#include <stdlib.h>
#include <stdio.h>
#include <unistd.h>
 
// ========================================
// MODEL 1: FORK PER CONNECTION
// ========================================
void fork_server_loop(int listen_fd) {
    while (1) {
        int client_fd = accept(listen_fd, NULL, NULL);
        if (client_fd == -1) continue;
        
        pid_t pid = fork();
        if (pid == 0) {
            // Child process
            close(listen_fd);  // Child doesn't need listening socket
            handle_client(client_fd);
            close(client_fd);
            _exit(0);
        } else if (pid > 0) {
            // Parent process
            close(client_fd);  // Parent doesn't need client socket
            // Also: handle SIGCHLD to reap children, or use waitpid()
        } else {
            // Fork failed
            close(client_fd);
        }
    }
}
 
// ========================================
// MODEL 2: THREAD PER CONNECTION
// ========================================
void *thread_handler(void *arg) {
    int client_fd = *(int*)arg;
    free(arg);
    
    handle_client(client_fd);
    close(client_fd);
    
    return NULL;
}
 
void thread_per_connection_loop(int listen_fd) {
    while (1) {
        int client_fd = accept(listen_fd, NULL, NULL);
        if (client_fd == -1) continue;
        
        int *fd_ptr = malloc(sizeof(int));
        *fd_ptr = client_fd;
        
        pthread_t tid;
        if (pthread_create(&tid, NULL, thread_handler, fd_ptr) != 0) {
            free(fd_ptr);
            close(client_fd);
            continue;
        }
        
        pthread_detach(tid);  // Auto-cleanup when thread exits
    }
}
 
// ========================================
// MODEL 3: THREAD POOL
// ========================================
typedef struct {
    int *queue;
    int head, tail, size, capacity;
    pthread_mutex_t mutex;
    pthread_cond_t not_empty;
    pthread_cond_t not_full;
    int shutdown;
} WorkQueue;
 
void *worker_thread(void *arg) {
    WorkQueue *q = arg;
    
    while (1) {
        pthread_mutex_lock(&q->mutex);
        
        while (q->size == 0 && !q->shutdown) {
            pthread_cond_wait(&q->not_empty, &q->mutex);
        }
        
        if (q->shutdown && q->size == 0) {
            pthread_mutex_unlock(&q->mutex);
            break;
        }
        
        int client_fd = q->queue[q->head];
        q->head = (q->head + 1) % q->capacity;
        q->size--;
        
        pthread_cond_signal(&q->not_full);
        pthread_mutex_unlock(&q->mutex);
        
        // Handle client outside the lock
        handle_client(client_fd);
        close(client_fd);
    }
    
    return NULL;
}
 
void thread_pool_loop(int listen_fd, WorkQueue *q) {
    while (1) {
        int client_fd = accept(listen_fd, NULL, NULL);
        if (client_fd == -1) continue;
        
        pthread_mutex_lock(&q->mutex);
        
        while (q->size == q->capacity) {
            pthread_cond_wait(&q->not_full, &q->mutex);
        }
        
        q->queue[q->tail] = client_fd;
        q->tail = (q->tail + 1) % q->capacity;
        q->size++;
        
        pthread_cond_signal(&q->not_empty);
        pthread_mutex_unlock(&q->mutex);
    }
}

C10K and Beyond

The 'C10K problem' (handling 10,000+ concurrent connections) drove the development of event-driven architectures. With thread-per-connection, 10K threads consume gigabytes of stack memory and cause excessive context switching. Event-driven servers like NGINX handle millions of connections with fixed thread count, fundamentally changing server architecture.

Event-Driven I/O Multiplexing

Event-driven servers use I/O multiplexing to monitor multiple sockets simultaneously with a single thread. When any socket has data available, the server processes it without blocking on others. I/O Multiplexing APIs:

API	Platform	Scalability	Notes
select()	POSIX (universal)	~1024 fds	FD_SETSIZE limit; O(n) scanning
poll()	POSIX	No limit	Still O(n) every call
epoll	Linux	Very high	O(1) operations; edge/level triggered
kqueue	BSD/macOS	Very high	Similar to epoll, different API
IOCP	Windows	Very high	Completion-based (different model)

For any serious server, epoll (Linux) or kqueue (BSD/Mac) is essential.

event_driven_server.c
C (Linux epoll)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
#include <sys/epoll.h>
#include <sys/socket.h>
#include <netinet/in.h>
#include <fcntl.h>
#include <stdio.h>
#include <unistd.h>
#include <errno.h>
 
#define MAX_EVENTS 1024
 
// Set socket to non-blocking mode
int set_nonblocking(int fd) {
    int flags = fcntl(fd, F_GETFL, 0);
    if (flags == -1) return -1;
    return fcntl(fd, F_SETFL, flags | O_NONBLOCK);
}
 
// Event-driven server using epoll
int run_epoll_server(uint16_t port) {
    // Create listening socket
    int listen_fd = socket(AF_INET, SOCK_STREAM | SOCK_NONBLOCK, 0);
    if (listen_fd == -1) return -1;
    
    int opt = 1;
    setsockopt(listen_fd, SOL_SOCKET, SO_REUSEADDR, &opt, sizeof(opt));
    
    struct sockaddr_in addr = {
        .sin_family = AF_INET,
        .sin_addr.s_addr = htonl(INADDR_ANY),
        .sin_port = htons(port)
    };
    
    if (bind(listen_fd, (struct sockaddr*)&addr, sizeof(addr)) == -1) {
        close(listen_fd);
        return -1;
    }
    
    if (listen(listen_fd, 128) == -1) {
        close(listen_fd);
        return -1;
    }
    
    // Create epoll instance
    int epoll_fd = epoll_create1(0);
    if (epoll_fd == -1) {
        close(listen_fd);
        return -1;
    }
    
    // Add listening socket to epoll
    struct epoll_event ev = {
        .events = EPOLLIN,
        .data.fd = listen_fd
    };
    epoll_ctl(epoll_fd, EPOLL_CTL_ADD, listen_fd, &ev);
    
    struct epoll_event events[MAX_EVENTS];
    printf("Event-driven server listening on port %d
", port);
    
    while (1) {
        int nfds = epoll_wait(epoll_fd, events, MAX_EVENTS, -1);
        
        for (int i = 0; i < nfds; i++) {
            int fd = events[i].data.fd;
            
            if (fd == listen_fd) {
                // New connection(s) available
                while (1) {
                    int client_fd = accept(listen_fd, NULL, NULL);
                    if (client_fd == -1) {
                        if (errno == EAGAIN || errno == EWOULDBLOCK) {
                            break;  // No more pending connections
                        }
                        perror("accept");
                        break;
                    }
                    
                    set_nonblocking(client_fd);
                    
                    struct epoll_event cev = {
                        .events = EPOLLIN | EPOLLET,  // Edge-triggered
                        .data.fd = client_fd
                    };
                    epoll_ctl(epoll_fd, EPOLL_CTL_ADD, client_fd, &cev);
                    
                    printf("New connection (fd=%d)
", client_fd);
                }
            } else {
                // Data available on client socket
                if (events[i].events & (EPOLLHUP | EPOLLERR)) {
                    // Error or hangup
                    close(fd);
                    continue;
                }
                
                if (events[i].events & EPOLLIN) {
                    char buf[4096];
                    while (1) {
                        ssize_t n = recv(fd, buf, sizeof(buf), 0);
                        
                        if (n == -1) {
                            if (errno == EAGAIN) break;  // No more data
                            close(fd);
                            break;
                        }
                        
                        if (n == 0) {
                            // Connection closed
                            printf("Connection closed (fd=%d)
", fd);
                            close(fd);
                            break;
                        }
                        
                        // Echo back (simplified; real code handles partial sends)
                        send(fd, buf, n, MSG_NOSIGNAL);
                    }
                }
            }
        }
    }
    
    close(epoll_fd);
    close(listen_fd);
    return 0;
}

Event-Driven Server Characteristics

•Non-blocking I/O is mandatory — Sockets must never block; blocking would stop the entire event loop.
•Single thread handles thousands of connections — No thread-per-connection overhead.
•State must be maintained explicitly — Can't store state in local variables; need per-connection data structures.
•No CPU-blocking operations in event loop — Long computations block all connections; offload to thread pool.
•Edge vs. level triggered — Edge (EPOLLET) notifies once per state change; level triggers repeatedly while data available.

Event-Driven Complexity

Event-driven programming inverts control flow—instead of reading in sequence, you respond to events. This makes logic harder to follow and debug. Libraries like libuv, libevent, and libev abstract this complexity. Modern languages provide async/await syntax that looks sequential but executes event-driven.

UDP Client/Server Patterns

UDP sockets have inherently simpler patterns due to their connectionless nature: Server: socket() \to Create datagram socket bind() \to Assign address Loop: recvfrom() \to process \to sendto() Client: socket() \to Create datagram socket Loop: sendto() \to recvfrom() No listen() or accept() needed—there's no connection establishment.

udp_server_client.c
C
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
#include <sys/socket.h>
#include <netinet/in.h>
#include <string.h>
#include <stdio.h>
#include <unistd.h>
 
// UDP Echo Server
int run_udp_echo_server(uint16_t port) {
    int sockfd = socket(AF_INET, SOCK_DGRAM, 0);
    if (sockfd == -1) return -1;
    
    struct sockaddr_in addr = {
        .sin_family = AF_INET,
        .sin_addr.s_addr = htonl(INADDR_ANY),
        .sin_port = htons(port)
    };
    
    if (bind(sockfd, (struct sockaddr*)&addr, sizeof(addr)) == -1) {
        close(sockfd);
        return -1;
    }
    
    printf("UDP server listening on port %d
", port);
    
    char buf[65536];  // Max UDP payload ~65KB
    struct sockaddr_in client_addr;
    socklen_t addr_len;
    
    while (1) {
        addr_len = sizeof(client_addr);
        
        ssize_t n = recvfrom(sockfd, buf, sizeof(buf), 0,
                            (struct sockaddr*)&client_addr, &addr_len);
        
        if (n == -1) {
            perror("recvfrom");
            continue;
        }
        
        // Echo back to the sender
        sendto(sockfd, buf, n, 0,
               (struct sockaddr*)&client_addr, addr_len);
    }
    
    close(sockfd);
    return 0;
}
 
// UDP Client
int udp_client_send_recv(const char *host, uint16_t port,
                         const void *request, size_t req_len,
                         void *response, size_t resp_len) {
    int sockfd = socket(AF_INET, SOCK_DGRAM, 0);
    if (sockfd == -1) return -1;
    
    // Set receive timeout (important for UDP!)
    struct timeval tv = { .tv_sec = 5, .tv_usec = 0 };
    setsockopt(sockfd, SOL_SOCKET, SO_RCVTIMEO, &tv, sizeof(tv));
    
    struct sockaddr_in server_addr = {
        .sin_family = AF_INET,
        .sin_port = htons(port)
    };
    inet_pton(AF_INET, host, &server_addr.sin_addr);
    
    // Send request
    if (sendto(sockfd, request, req_len, 0,
               (struct sockaddr*)&server_addr, sizeof(server_addr)) == -1) {
        close(sockfd);
        return -1;
    }
    
    // Receive response
    ssize_t n = recvfrom(sockfd, response, resp_len, 0, NULL, NULL);
    
    close(sockfd);
    return n;
}
 
// Connected UDP socket (alternative pattern)
int connected_udp_client(const char *host, uint16_t port) {
    int sockfd = socket(AF_INET, SOCK_DGRAM, 0);
    if (sockfd == -1) return -1;
    
    struct sockaddr_in server_addr = {
        .sin_family = AF_INET,
        .sin_port = htons(port)
    };
    inet_pton(AF_INET, host, &server_addr.sin_addr);
    
    // "Connect" UDP socket (sets default destination)
    if (connect(sockfd, (struct sockaddr*)&server_addr, 
                sizeof(server_addr)) == -1) {
        close(sockfd);
        return -1;
    }
    
    // Now can use send()/recv() instead of sendto()/recvfrom()
    // Also enables ICMP error reporting for this destination
    send(sockfd, "Hello", 5, 0);
    
    char buf[1024];
    ssize_t n = recv(sockfd, buf, sizeof(buf), 0);
    // n == -1 with errno == ECONNREFUSED if port unreachable
    
    close(sockfd);
    return 0;
}

Connected UDP Sockets

Calling connect() on a UDP socket doesn't establish a connection—it sets a default destination address. Benefits: use send()/recv() instead of sendto()/recvfrom(), receive ICMP errors (connection refused), and filter incoming datagrams to only the connected peer. Useful for request/response protocols to a single server.

UDP vs. TCP Client/Server Differences:

Aspect	TCP	UDP
Connection setup	Required (3-way handshake)	None
Accept/listen	Required for server	Not applicable
Per-client socket	Yes (from accept())	No (one socket, many clients)
Message boundaries	Not preserved (stream)	Preserved (datagrams)
Reliability	Guaranteed	Application responsibility
Ordering	Guaranteed	Application responsibility
NAT traversal	Easier (connection state)	Harder (stateless)

Architecture and Design Considerations

Building production-quality client/server applications requires careful attention to several cross-cutting concerns: Connection Lifecycle Management: Connections go through distinct phases: setup, active, draining, closed. Each phase requires appropriate handling: Setup : Validate credentials, negotiate protocol version, allocate resources Active : Handle requests, manage timeouts, track activity Draining : Complete pending work before shutdown Closed : Release resources, update metrics, log session Resource Bounds: Production servers must protect themselves from resource exhaustion: Maximum concurrent connections Per-client rate limits Request size limits Connection timeout enforcement Memory usage caps

Production Server Checklist

•Graceful shutdown — Stop accepting new connections; complete in-flight requests; timeout and terminate stragglers.
•Health monitoring — Expose endpoints for load balancers to check server health; track connection counts, latency, errors.
•Logging and tracing — Log connection events, errors, slow requests. Include request IDs for distributed tracing.
•Configuration — Make ports, timeouts, pool sizes, and limits configurable without code changes.
•Signal handling — Handle SIGTERM for graceful shutdown, SIGHUP for config reload, SIGPIPE with MSG_NOSIGNAL.
•Error handling — Distinguish transient errors (retry) from permanent failures (log and fail). Never crash on client errors.
•Backpressure — When overloaded, reject new connections cleanly rather than accepting and failing later.

Protocol Design: The application protocol layered over sockets significantly impacts implementation:

Protocol Pattern	Description	Example
Request-Response	Client sends request, waits for response	HTTP/1.1
Streaming	Data flows continuously in one/both directions	WebSocket, gRPC streaming
Pipelining	Client sends multiple requests without waiting	HTTP/1.1 pipelining
Multiplexing	Multiple logical streams over one connection	HTTP/2, QUIC

Keep-Alive vs. Connection-Per-Request: Keep-alive connections amortize TCP handshake overhead across multiple requests: HTTP/1.0: Connection-per-request (default) HTTP/1.1: Keep-alive (default) HTTP/2+: Multiplexed streams over long-lived connection For internal services with many requests between the same endpoints, connection pooling provides the best of both worlds.

The Thundering Herd

When multiple threads/processes wait on the same listening socket, an incoming connection can wake ALL of them—but only one can accept it. This 'thundering herd' wastes CPU on spurious wakeups. Solutions: SO_REUSEPORT (each process has its own listening socket), EPOLLEXCLUSIVE (Linux 4.5+), or application-level connection distribution.

Computer NetworksTransport Layer Concepts

Sockets

LevelIntermediate

Duration60 mins

TopicTransport Layer Concepts

4 / 5

Client/Server Sockets

Architectural Patterns for Network Applications

The socket API provides primitives; building applications requires patterns . The most fundamental pattern in network programming is the client/server model, where server processes wait for connection requests and client processes initiate contact. This seemingly simple model has profound architectural implications. How does a server handle multiple clients? Should it dedicate a thread per connection or use event-driven I/O? How do clients handle slow or unresponsive servers? These questions have shaped decades of software architecture, from Apache's prefork model to NGINX's event-driven design to modern async/await patterns. Mastering client/server socket programming means understanding not just the code, but the architectural tradeoffs that determine scalability, latency, and resource utilization.

What You Will Learn

By the end of this page, you will understand the client and server socket lifecycles, iterative and concurrent server models, the roles of listening and connected sockets, and how to design for scalability. You'll be equipped to architect network services for any scale.

The Client/Server Model

The client/server model is an asymmetric communication pattern where: Server: Waits passively for connections (listening) Runs continuously (daemon/service) Serves multiple clients simultaneously or sequentially Has a well-known address (fixed IP/port) Typically provides a specific service (HTTP, database, email) Client: Initiates connections actively Runs when needed, terminates when done Connects to one or more servers Uses ephemeral local ports Requests services from servers This model decouples service providers from consumers, enabling the distributed systems architecture that powers the modern internet.

Converting Mermaid diagram...

Socket Lifecycle Comparison:

Server vs. Client Socket Lifecycle
Phase	Server	Client
Creation	socket()	socket()
Address Assignment	bind() to known port	Automatic or bind() to ephemeral
Role Designation	listen() → passive mode	—
Connection Phase	accept() → blocks/waits	connect() → initiates
Data Transfer	recv()/send() on accepted socket	recv()/send() on connected socket
Termination	close() client socket; keep listening	close() socket
Lifespan	Long-running (daemon)	Short-lived (session)

The Two Server Sockets

A key insight: servers have TWO types of sockets. The LISTENING socket (created once, used for accept()) and CONNECTED sockets (one per client, used for data transfer). The listening socket never sends or receives application data—it only exists to accept new connections.

Client Implementation Patterns

Client sockets follow a straightforward pattern: connect, communicate, disconnect. However, production clients require careful error handling, timeout management, and connection reuse. Basic Client Pattern: 1. Create socket: socket() 2. Connect to server: connect() 3. Send request: send() 4. Receive response: recv() (loop until complete) 5. Close connection: close()

client_patterns.c
C
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
#include <sys/socket.h>
#include <netdb.h>
#include <string.h>
#include <stdio.h>
#include <unistd.h>
#include <errno.h>
 
// Production-quality TCP client
typedef struct {
    int sockfd;
    char host[256];
    char port[16];
    int connected;
} Client;
 
int client_connect(Client *c, const char *host, const char *port) {
    struct addrinfo hints = {0}, *res, *p;
    hints.ai_family = AF_UNSPEC;     // IPv4 or IPv6
    hints.ai_socktype = SOCK_STREAM; // TCP
    
    int err = getaddrinfo(host, port, &hints, &res);
    if (err != 0) {
        fprintf(stderr, "Resolution failed: %s
", gai_strerror(err));
        return -1;
    }
    
    // Try each resolved address
    for (p = res; p != NULL; p = p->ai_next) {
        c->sockfd = socket(p->ai_family, p->ai_socktype, p->ai_protocol);
        if (c->sockfd == -1) continue;
        
        if (connect(c->sockfd, p->ai_addr, p->ai_addrlen) == 0) {
            break;  // Success
        }
        
        close(c->sockfd);
        c->sockfd = -1;
    }
    
    freeaddrinfo(res);
    
    if (p == NULL) {
        fprintf(stderr, "Failed to connect to %s:%s
", host, port);
        return -1;
    }
    
    strncpy(c->host, host, sizeof(c->host) - 1);
    strncpy(c->port, port, sizeof(c->port) - 1);
    c->connected = 1;
    
    return 0;
}
 
ssize_t client_send(Client *c, const void *data, size_t len) {
    if (!c->connected) return -1;
    
    size_t sent = 0;
    while (sent < len) {
        ssize_t n = send(c->sockfd, (char*)data + sent, len - sent, 
                        MSG_NOSIGNAL);
        if (n == -1) {
            if (errno == EINTR) continue;
            c->connected = 0;
            return -1;
        }
        sent += n;
    }
    return sent;
}
 
ssize_t client_recv(Client *c, void *buf, size_t len) {
    if (!c->connected) return -1;
    
    ssize_t n = recv(c->sockfd, buf, len, 0);
    if (n <= 0) {
        c->connected = 0;
    }
    return n;
}
 
void client_close(Client *c) {
    if (c->sockfd >= 0) {
        close(c->sockfd);
        c->sockfd = -1;
    }
    c->connected = 0;
}
 
// Example usage: simple HTTP request
void example_http_request() {
    Client c = {.sockfd = -1};
    
    if (client_connect(&c, "example.com", "80") != 0) {
        return;
    }
    
    const char *request = "GET / HTTP/1.1\r
"
                          "Host: example.com\r
"
                          "Connection: close\r
"
                          "\r
";
    
    client_send(&c, request, strlen(request));
    
    char buf[4096];
    ssize_t n;
    while ((n = client_recv(&c, buf, sizeof(buf) - 1)) > 0) {
        buf[n] = '\0';
        printf("%s", buf);
    }
    
    client_close(&c);
}

Client Best Practices

•Use getaddrinfo() — Support both IPv4 and IPv6 transparently. Try all returned addresses for redundancy.
•Implement connection timeouts — Non-blocking connect with select/poll prevents hanging on unreachable servers.
•Handle partial sends/receives — Loop until all data is transferred; never assume single-call completion.
•Implement reconnection logic — Network connections fail; clients should retry with exponential backoff.
•Use connection pooling — Reusing connections amortizes TCP handshake overhead for repeated requests.
•Set appropriate socket options — TCP_NODELAY for latency-sensitive apps; appropriate buffer sizes for throughput.

The Slow Server Problem

A blocking client hangs indefinitely if the server stops responding. Production clients must implement timeouts using: (1) non-blocking sockets with select/poll/epoll, (2) SO_RCVTIMEO/SO_SNDTIMEO socket options, or (3) application-level timer threads. No network call should block indefinitely.

Iterative Server Model

The simplest server model handles one client at a time: accept a connection, process the entire request, close the connection, then accept the next. This is the iterative server . Characteristics: Single-threaded, single-process Clients are served sequentially Simple to implement and debug No concurrency complexity Limitations: Subsequent clients blocked during processing Poor utilization of multi-core systems Unsuitable for long-running requests No fault isolation between requests

iterative_server.c
C
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
#include <sys/socket.h>
#include <netinet/in.h>
#include <string.h>
#include <stdio.h>
#include <unistd.h>
#include <signal.h>
 
static volatile int running = 1;
 
void handle_sigint(int sig) {
    running = 0;
}
 
// Handle a single client connection
void handle_client(int client_fd) {
    char buf[4096];
    ssize_t n;
    
    // Simple echo server: read and echo back
    while ((n = recv(client_fd, buf, sizeof(buf), 0)) > 0) {
        // Echo the data back
        ssize_t sent = 0;
        while (sent < n) {
            ssize_t s = send(client_fd, buf + sent, n - sent, MSG_NOSIGNAL);
            if (s <= 0) return;  // Error or closed
            sent += s;
        }
    }
}
 
// Iterative server main loop
int run_iterative_server(uint16_t port) {
    signal(SIGINT, handle_sigint);
    signal(SIGPIPE, SIG_IGN);  // Ignore broken pipe
    
    // Create listening socket
    int listen_fd = socket(AF_INET, SOCK_STREAM, 0);
    if (listen_fd == -1) {
        perror("socket");
        return -1;
    }
    
    // Allow address reuse
    int opt = 1;
    setsockopt(listen_fd, SOL_SOCKET, SO_REUSEADDR, &opt, sizeof(opt));
    
    // Bind
    struct sockaddr_in addr = {0};
    addr.sin_family = AF_INET;
    addr.sin_addr.s_addr = htonl(INADDR_ANY);
    addr.sin_port = htons(port);
    
    if (bind(listen_fd, (struct sockaddr*)&addr, sizeof(addr)) == -1) {
        perror("bind");
        close(listen_fd);
        return -1;
    }
    
    // Listen
    if (listen(listen_fd, 128) == -1) {
        perror("listen");
        close(listen_fd);
        return -1;
    }
    
    printf("Iterative server listening on port %d
", port);
    
    // Main loop: accept and handle one at a time
    while (running) {
        struct sockaddr_in client_addr;
        socklen_t addr_len = sizeof(client_addr);
        
        int client_fd = accept(listen_fd, 
                               (struct sockaddr*)&client_addr, 
                               &addr_len);
        
        if (client_fd == -1) {
            if (errno == EINTR) continue;  // Interrupted, retry
            perror("accept");
            continue;
        }
        
        printf("Client connected (fd=%d)
", client_fd);
        
        // Handle this client completely before accepting another
        handle_client(client_fd);
        
        printf("Client disconnected (fd=%d)
", client_fd);
        close(client_fd);
    }
    
    close(listen_fd);
    printf("Server shutdown
");
    return 0;
}

When to Use Iterative Servers:

Scenario	Suitable?	Reason
Simple echo server	✓	Fast processing, no blocking
DNS server (simple)	✓	Quick queries, stateless
High-traffic web server	✗	Clients queue behind slow requests
Database server	✗	Queries may take seconds
Development/testing	✓	Easy debugging, reproducible behavior
Embedded systems	✓	Minimal resource usage

The Head-of-Line Blocking Problem

In iterative servers, a single slow client blocks all others. If Client A sends a request that takes 10 seconds to process, Clients B, C, D must all wait—even if their requests would complete in milliseconds. This head-of-line blocking is the fundamental limitation that motivates concurrent server designs.

Concurrent Server Models

To handle multiple clients simultaneously, servers employ concurrency. Several models exist, each with distinct tradeoffs: 1. Process-Per-Connection (fork): fork() after accept() creates child process for each client Complete memory isolation between clients High overhead (memory, context switches) Used by: Early Apache, PostgreSQL 2. Thread-Per-Connection: pthread_create() after accept() creates thread for each client Shared memory between threads (faster IPC) Lower overhead than processes, still significant Used by: Many traditional servers 3. Thread Pool: Pre-created pool of worker threads Accept in main thread, dispatch to idle worker Bounds resource usage, reduces thread creation overhead Used by: Tomcat, many database servers 4. Event-Driven (Single-Threaded): One thread handles all connections using I/O multiplexing Non-blocking I/O with select/poll/epoll No concurrency overhead, but complex state management Used by: NGINX, Node.js, Redis 5. Hybrid (Event-Driven + Thread Pool): Event loop accepts and manages I/O Thread pool for blocking/CPU-intensive operations Best of both worlds for many workloads Used by: Modern servers

Concurrent Server Model Comparison
Model	Connections	Memory	Latency	Complexity
Iterative	1 (blocking)	Minimal	High for waiting clients	Simple
Fork per connection	~1,000	High (per-process)	Good	Simple
Thread per connection	~10,000	Moderate (per-thread)	Good	Moderate
Thread pool	~10,000	Bounded	Good	Moderate
Event-driven	~100,000+	Minimal	Excellent	Complex
Hybrid	~100,000+	Bounded	Excellent	Complex

concurrent_models.c
C
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
#include <sys/socket.h>
#include <pthread.h>
#include <stdlib.h>
#include <stdio.h>
#include <unistd.h>
 
// ========================================
// MODEL 1: FORK PER CONNECTION
// ========================================
void fork_server_loop(int listen_fd) {
    while (1) {
        int client_fd = accept(listen_fd, NULL, NULL);
        if (client_fd == -1) continue;
        
        pid_t pid = fork();
        if (pid == 0) {
            // Child process
            close(listen_fd);  // Child doesn't need listening socket
            handle_client(client_fd);
            close(client_fd);
            _exit(0);
        } else if (pid > 0) {
            // Parent process
            close(client_fd);  // Parent doesn't need client socket
            // Also: handle SIGCHLD to reap children, or use waitpid()
        } else {
            // Fork failed
            close(client_fd);
        }
    }
}
 
// ========================================
// MODEL 2: THREAD PER CONNECTION
// ========================================
void *thread_handler(void *arg) {
    int client_fd = *(int*)arg;
    free(arg);
    
    handle_client(client_fd);
    close(client_fd);
    
    return NULL;
}
 
void thread_per_connection_loop(int listen_fd) {
    while (1) {
        int client_fd = accept(listen_fd, NULL, NULL);
        if (client_fd == -1) continue;
        
        int *fd_ptr = malloc(sizeof(int));
        *fd_ptr = client_fd;
        
        pthread_t tid;
        if (pthread_create(&tid, NULL, thread_handler, fd_ptr) != 0) {
            free(fd_ptr);
            close(client_fd);
            continue;
        }
        
        pthread_detach(tid);  // Auto-cleanup when thread exits
    }
}
 
// ========================================
// MODEL 3: THREAD POOL
// ========================================
typedef struct {
    int *queue;
    int head, tail, size, capacity;
    pthread_mutex_t mutex;
    pthread_cond_t not_empty;
    pthread_cond_t not_full;
    int shutdown;
} WorkQueue;
 
void *worker_thread(void *arg) {
    WorkQueue *q = arg;
    
    while (1) {
        pthread_mutex_lock(&q->mutex);
        
        while (q->size == 0 && !q->shutdown) {
            pthread_cond_wait(&q->not_empty, &q->mutex);
        }
        
        if (q->shutdown && q->size == 0) {
            pthread_mutex_unlock(&q->mutex);
            break;
        }
        
        int client_fd = q->queue[q->head];
        q->head = (q->head + 1) % q->capacity;
        q->size--;
        
        pthread_cond_signal(&q->not_full);
        pthread_mutex_unlock(&q->mutex);
        
        // Handle client outside the lock
        handle_client(client_fd);
        close(client_fd);
    }
    
    return NULL;
}
 
void thread_pool_loop(int listen_fd, WorkQueue *q) {
    while (1) {
        int client_fd = accept(listen_fd, NULL, NULL);
        if (client_fd == -1) continue;
        
        pthread_mutex_lock(&q->mutex);
        
        while (q->size == q->capacity) {
            pthread_cond_wait(&q->not_full, &q->mutex);
        }
        
        q->queue[q->tail] = client_fd;
        q->tail = (q->tail + 1) % q->capacity;
        q->size++;
        
        pthread_cond_signal(&q->not_empty);
        pthread_mutex_unlock(&q->mutex);
    }
}

C10K and Beyond

The 'C10K problem' (handling 10,000+ concurrent connections) drove the development of event-driven architectures. With thread-per-connection, 10K threads consume gigabytes of stack memory and cause excessive context switching. Event-driven servers like NGINX handle millions of connections with fixed thread count, fundamentally changing server architecture.

Event-Driven I/O Multiplexing

Event-driven servers use I/O multiplexing to monitor multiple sockets simultaneously with a single thread. When any socket has data available, the server processes it without blocking on others. I/O Multiplexing APIs:

API	Platform	Scalability	Notes
select()	POSIX (universal)	~1024 fds	FD_SETSIZE limit; O(n) scanning
poll()	POSIX	No limit	Still O(n) every call
epoll	Linux	Very high	O(1) operations; edge/level triggered
kqueue	BSD/macOS	Very high	Similar to epoll, different API
IOCP	Windows	Very high	Completion-based (different model)

For any serious server, epoll (Linux) or kqueue (BSD/Mac) is essential.

event_driven_server.c
C (Linux epoll)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
#include <sys/epoll.h>
#include <sys/socket.h>
#include <netinet/in.h>
#include <fcntl.h>
#include <stdio.h>
#include <unistd.h>
#include <errno.h>
 
#define MAX_EVENTS 1024
 
// Set socket to non-blocking mode
int set_nonblocking(int fd) {
    int flags = fcntl(fd, F_GETFL, 0);
    if (flags == -1) return -1;
    return fcntl(fd, F_SETFL, flags | O_NONBLOCK);
}
 
// Event-driven server using epoll
int run_epoll_server(uint16_t port) {
    // Create listening socket
    int listen_fd = socket(AF_INET, SOCK_STREAM | SOCK_NONBLOCK, 0);
    if (listen_fd == -1) return -1;
    
    int opt = 1;
    setsockopt(listen_fd, SOL_SOCKET, SO_REUSEADDR, &opt, sizeof(opt));
    
    struct sockaddr_in addr = {
        .sin_family = AF_INET,
        .sin_addr.s_addr = htonl(INADDR_ANY),
        .sin_port = htons(port)
    };
    
    if (bind(listen_fd, (struct sockaddr*)&addr, sizeof(addr)) == -1) {
        close(listen_fd);
        return -1;
    }
    
    if (listen(listen_fd, 128) == -1) {
        close(listen_fd);
        return -1;
    }
    
    // Create epoll instance
    int epoll_fd = epoll_create1(0);
    if (epoll_fd == -1) {
        close(listen_fd);
        return -1;
    }
    
    // Add listening socket to epoll
    struct epoll_event ev = {
        .events = EPOLLIN,
        .data.fd = listen_fd
    };
    epoll_ctl(epoll_fd, EPOLL_CTL_ADD, listen_fd, &ev);
    
    struct epoll_event events[MAX_EVENTS];
    printf("Event-driven server listening on port %d
", port);
    
    while (1) {
        int nfds = epoll_wait(epoll_fd, events, MAX_EVENTS, -1);
        
        for (int i = 0; i < nfds; i++) {
            int fd = events[i].data.fd;
            
            if (fd == listen_fd) {
                // New connection(s) available
                while (1) {
                    int client_fd = accept(listen_fd, NULL, NULL);
                    if (client_fd == -1) {
                        if (errno == EAGAIN || errno == EWOULDBLOCK) {
                            break;  // No more pending connections
                        }
                        perror("accept");
                        break;
                    }
                    
                    set_nonblocking(client_fd);
                    
                    struct epoll_event cev = {
                        .events = EPOLLIN | EPOLLET,  // Edge-triggered
                        .data.fd = client_fd
                    };
                    epoll_ctl(epoll_fd, EPOLL_CTL_ADD, client_fd, &cev);
                    
                    printf("New connection (fd=%d)
", client_fd);
                }
            } else {
                // Data available on client socket
                if (events[i].events & (EPOLLHUP | EPOLLERR)) {
                    // Error or hangup
                    close(fd);
                    continue;
                }
                
                if (events[i].events & EPOLLIN) {
                    char buf[4096];
                    while (1) {
                        ssize_t n = recv(fd, buf, sizeof(buf), 0);
                        
                        if (n == -1) {
                            if (errno == EAGAIN) break;  // No more data
                            close(fd);
                            break;
                        }
                        
                        if (n == 0) {
                            // Connection closed
                            printf("Connection closed (fd=%d)
", fd);
                            close(fd);
                            break;
                        }
                        
                        // Echo back (simplified; real code handles partial sends)
                        send(fd, buf, n, MSG_NOSIGNAL);
                    }
                }
            }
        }
    }
    
    close(epoll_fd);
    close(listen_fd);
    return 0;
}

Event-Driven Server Characteristics

•Non-blocking I/O is mandatory — Sockets must never block; blocking would stop the entire event loop.
•Single thread handles thousands of connections — No thread-per-connection overhead.
•State must be maintained explicitly — Can't store state in local variables; need per-connection data structures.
•No CPU-blocking operations in event loop — Long computations block all connections; offload to thread pool.
•Edge vs. level triggered — Edge (EPOLLET) notifies once per state change; level triggers repeatedly while data available.

Event-Driven Complexity

Event-driven programming inverts control flow—instead of reading in sequence, you respond to events. This makes logic harder to follow and debug. Libraries like libuv, libevent, and libev abstract this complexity. Modern languages provide async/await syntax that looks sequential but executes event-driven.

UDP Client/Server Patterns

UDP sockets have inherently simpler patterns due to their connectionless nature: Server: socket() \to Create datagram socket bind() \to Assign address Loop: recvfrom() \to process \to sendto() Client: socket() \to Create datagram socket Loop: sendto() \to recvfrom() No listen() or accept() needed—there's no connection establishment.

udp_server_client.c
C
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
#include <sys/socket.h>
#include <netinet/in.h>
#include <string.h>
#include <stdio.h>
#include <unistd.h>
 
// UDP Echo Server
int run_udp_echo_server(uint16_t port) {
    int sockfd = socket(AF_INET, SOCK_DGRAM, 0);
    if (sockfd == -1) return -1;
    
    struct sockaddr_in addr = {
        .sin_family = AF_INET,
        .sin_addr.s_addr = htonl(INADDR_ANY),
        .sin_port = htons(port)
    };
    
    if (bind(sockfd, (struct sockaddr*)&addr, sizeof(addr)) == -1) {
        close(sockfd);
        return -1;
    }
    
    printf("UDP server listening on port %d
", port);
    
    char buf[65536];  // Max UDP payload ~65KB
    struct sockaddr_in client_addr;
    socklen_t addr_len;
    
    while (1) {
        addr_len = sizeof(client_addr);
        
        ssize_t n = recvfrom(sockfd, buf, sizeof(buf), 0,
                            (struct sockaddr*)&client_addr, &addr_len);
        
        if (n == -1) {
            perror("recvfrom");
            continue;
        }
        
        // Echo back to the sender
        sendto(sockfd, buf, n, 0,
               (struct sockaddr*)&client_addr, addr_len);
    }
    
    close(sockfd);
    return 0;
}
 
// UDP Client
int udp_client_send_recv(const char *host, uint16_t port,
                         const void *request, size_t req_len,
                         void *response, size_t resp_len) {
    int sockfd = socket(AF_INET, SOCK_DGRAM, 0);
    if (sockfd == -1) return -1;
    
    // Set receive timeout (important for UDP!)
    struct timeval tv = { .tv_sec = 5, .tv_usec = 0 };
    setsockopt(sockfd, SOL_SOCKET, SO_RCVTIMEO, &tv, sizeof(tv));
    
    struct sockaddr_in server_addr = {
        .sin_family = AF_INET,
        .sin_port = htons(port)
    };
    inet_pton(AF_INET, host, &server_addr.sin_addr);
    
    // Send request
    if (sendto(sockfd, request, req_len, 0,
               (struct sockaddr*)&server_addr, sizeof(server_addr)) == -1) {
        close(sockfd);
        return -1;
    }
    
    // Receive response
    ssize_t n = recvfrom(sockfd, response, resp_len, 0, NULL, NULL);
    
    close(sockfd);
    return n;
}
 
// Connected UDP socket (alternative pattern)
int connected_udp_client(const char *host, uint16_t port) {
    int sockfd = socket(AF_INET, SOCK_DGRAM, 0);
    if (sockfd == -1) return -1;
    
    struct sockaddr_in server_addr = {
        .sin_family = AF_INET,
        .sin_port = htons(port)
    };
    inet_pton(AF_INET, host, &server_addr.sin_addr);
    
    // "Connect" UDP socket (sets default destination)
    if (connect(sockfd, (struct sockaddr*)&server_addr, 
                sizeof(server_addr)) == -1) {
        close(sockfd);
        return -1;
    }
    
    // Now can use send()/recv() instead of sendto()/recvfrom()
    // Also enables ICMP error reporting for this destination
    send(sockfd, "Hello", 5, 0);
    
    char buf[1024];
    ssize_t n = recv(sockfd, buf, sizeof(buf), 0);
    // n == -1 with errno == ECONNREFUSED if port unreachable
    
    close(sockfd);
    return 0;
}

Connected UDP Sockets

Calling connect() on a UDP socket doesn't establish a connection—it sets a default destination address. Benefits: use send()/recv() instead of sendto()/recvfrom(), receive ICMP errors (connection refused), and filter incoming datagrams to only the connected peer. Useful for request/response protocols to a single server.

UDP vs. TCP Client/Server Differences:

Aspect	TCP	UDP
Connection setup	Required (3-way handshake)	None
Accept/listen	Required for server	Not applicable
Per-client socket	Yes (from accept())	No (one socket, many clients)
Message boundaries	Not preserved (stream)	Preserved (datagrams)
Reliability	Guaranteed	Application responsibility
Ordering	Guaranteed	Application responsibility
NAT traversal	Easier (connection state)	Harder (stateless)

Architecture and Design Considerations

Building production-quality client/server applications requires careful attention to several cross-cutting concerns: Connection Lifecycle Management: Connections go through distinct phases: setup, active, draining, closed. Each phase requires appropriate handling: Setup : Validate credentials, negotiate protocol version, allocate resources Active : Handle requests, manage timeouts, track activity Draining : Complete pending work before shutdown Closed : Release resources, update metrics, log session Resource Bounds: Production servers must protect themselves from resource exhaustion: Maximum concurrent connections Per-client rate limits Request size limits Connection timeout enforcement Memory usage caps

Production Server Checklist

•Graceful shutdown — Stop accepting new connections; complete in-flight requests; timeout and terminate stragglers.
•Health monitoring — Expose endpoints for load balancers to check server health; track connection counts, latency, errors.
•Logging and tracing — Log connection events, errors, slow requests. Include request IDs for distributed tracing.
•Configuration — Make ports, timeouts, pool sizes, and limits configurable without code changes.
•Signal handling — Handle SIGTERM for graceful shutdown, SIGHUP for config reload, SIGPIPE with MSG_NOSIGNAL.
•Error handling — Distinguish transient errors (retry) from permanent failures (log and fail). Never crash on client errors.
•Backpressure — When overloaded, reject new connections cleanly rather than accepting and failing later.

Protocol Design: The application protocol layered over sockets significantly impacts implementation:

Protocol Pattern	Description	Example
Request-Response	Client sends request, waits for response	HTTP/1.1
Streaming	Data flows continuously in one/both directions	WebSocket, gRPC streaming
Pipelining	Client sends multiple requests without waiting	HTTP/1.1 pipelining
Multiplexing	Multiple logical streams over one connection	HTTP/2, QUIC

Keep-Alive vs. Connection-Per-Request: Keep-alive connections amortize TCP handshake overhead across multiple requests: HTTP/1.0: Connection-per-request (default) HTTP/1.1: Keep-alive (default) HTTP/2+: Multiplexed streams over long-lived connection For internal services with many requests between the same endpoints, connection pooling provides the best of both worlds.

The Thundering Herd

When multiple threads/processes wait on the same listening socket, an incoming connection can wake ALL of them—but only one can accept it. This 'thundering herd' wastes CPU on spurious wakeups. Solutions: SO_REUSEPORT (each process has its own listening socket), EPOLLEXCLUSIVE (Linux 4.5+), or application-level connection distribution.

Client/Server Sockets

Architectural Patterns for Network Applications

The Client/Server Model

Client Implementation Patterns

Iterative Server Model

Concurrent Server Models

Event-Driven I/O Multiplexing

UDP Client/Server Patterns

Architecture and Design Considerations

There’s more to understand.

Client/Server Sockets

Architectural Patterns for Network Applications

The Client/Server Model

Client Implementation Patterns

Iterative Server Model

Concurrent Server Models

Event-Driven I/O Multiplexing

UDP Client/Server Patterns

Architecture and Design Considerations

There’s more to understand.