Socket Address

For two processes to communicate across a network, they must be able to find each other. This seemingly simple requirement encompasses one of the most critical aspects of network programming: socket addressing. How do we uniquely identify a socket among billions of potential endpoints across the global Internet?

The answer lies in a carefully designed addressing scheme that combines hierarchical components—IP addresses to identify machines, and port numbers to identify specific processes on those machines. Together, these form the socket address, the fundamental unit of endpoint identification in TCP/IP networking.

Understanding socket addressing is essential not just for programming, but for debugging, security analysis, and system design. Every "connection refused" error, every firewall rule, and every load balancer configuration ultimately deals with socket addresses.

A socket address is a composite identifier that uniquely locates a socket within a network. In the Internet Protocol suite, a socket address consists of two fundamental components:

1. IP Address (Network Identifier):

• Identifies the machine (host) on the network
• IPv4: 32-bit address (e.g., 192.168.1.100)
• IPv6: 128-bit address (e.g., 2001:db8::1)
• Enables routing across network boundaries

2. Port Number (Process Identifier):

• Identifies the specific process/service on the machine
• 16-bit unsigned integer (range: 0-65535)
• Enables multiple network applications on one host

Together, an IP address and port number form a transport address or endpoint. This combination is often written as IP:Port (e.g., 192.168.1.100:8080 or [2001:db8::1]:443 for IPv6).

Port Number Classification:

Ports are divided into three ranges with different intended uses:

Well-known ports require root/administrator privileges to bind on most systems—a security measure preventing unprivileged processes from impersonating critical services.

The Address Uniqueness Requirement:

Within a single machine, no two sockets can be bound to the same socket address (IP + port) simultaneously for the same protocol. This uniqueness constraint is fundamental—it's how the operating system knows which socket should receive incoming data.

However, the same port number can be used:

• On different IP addresses (multi-homed hosts)
• By different protocols (TCP and UDP can both use port 53)
• With address reuse options (SO_REUSEADDR, SO_REUSEPORT)

The socket API represents addresses using structured data types. Understanding these structures is essential for socket programming, as they appear in nearly every socket operation.

The Generic Socket Address (sockaddr):

The socket API was designed to be protocol-independent. To achieve this, it uses a generic address structure that can represent addresses from any protocol family:

struct sockaddr {
    sa_family_t sa_family;    // Address family (AF_INET, AF_INET6, etc.)
    char        sa_data[14];  // Protocol-specific address data
};

This generic structure is 16 bytes and serves as a common base type. Functions like bind(), connect(), and accept() accept pointers to sockaddr, allowing them to work with any address family.

IPv4 Address Structure (sockaddr_in):

struct sockaddr_in {
    sa_family_t    sin_family;  // AF_INET
    in_port_t      sin_port;    // 16-bit port (network byte order)
    struct in_addr sin_addr;    // 32-bit IPv4 address
    char           sin_zero[8]; // Padding to match sockaddr size
};

struct in_addr {
    uint32_t s_addr;            // IPv4 address (network byte order)
};

IPv6 Address Structure (sockaddr_in6):

struct sockaddr_in6 {
    sa_family_t     sin6_family;   // AF_INET6
    in_port_t       sin6_port;     // 16-bit port (network byte order)
    uint32_t        sin6_flowinfo; // Flow information
    struct in6_addr sin6_addr;     // 128-bit IPv6 address
    uint32_t        sin6_scope_id; // Scope ID (for link-local addresses)
};

struct in6_addr {
    uint8_t s6_addr[16];           // IPv6 address bytes
};

Storage-Size Address Structure (sockaddr_storage):

When writing protocol-independent code that must handle both IPv4 and IPv6, use sockaddr_storage—a structure large enough to hold any socket address:

struct sockaddr_storage {
    sa_family_t ss_family;  // Address family
    // Large enough buffer for any address type
    // Implementation-defined padding and alignment
};

This is particularly important when calling accept() or recvfrom(), where you don't know in advance whether you'll receive an IPv4 or IPv6 connection. Using sockaddr_storage ensures sufficient space for either.

While a single socket address (IP + port) identifies one endpoint, a complete connection is identified by a 5-tuple—five values that together uniquely distinguish any connection in the system:

1. Protocol (TCP or UDP)
2. Source IP Address
3. Source Port Number
4. Destination IP Address
5. Destination Port Number

This 5-tuple is critical because it enables:

• Demultiplexing: The OS routes incoming data to the correct socket
• NAT traversal: Network Address Translators track connections by 5-tuple
• Firewall rules: Security policies match on 5-tuple components
• Connection tracking: Load balancers and routers identify flows

Connection Uniqueness Scenarios:

Consider how the 5-tuple enables multiple simultaneous connections:

Scenario 1: Multiple clients to same server

Connection A: TCP, 192.168.1.5:50000 → 10.0.0.1:80
Connection B: TCP, 192.168.1.5:50001 → 10.0.0.1:80
Connection C: TCP, 192.168.1.6:50000 → 10.0.0.1:80

All three connections go to the same server socket, but each has a unique 5-tuple.

Scenario 2: Same client to multiple servers

Connection D: TCP, 192.168.1.5:50002 → 10.0.0.1:80 (Web server)
Connection E: TCP, 192.168.1.5:50003 → 10.0.0.2:443 (API server)
Connection F: TCP, 192.168.1.5:50004 → 10.0.0.3:5432 (Database)

One client maintains multiple simultaneous connections.

Scenario 3: TCP and UDP to same endpoint

Connection G: TCP, 192.168.1.5:50005 → 10.0.0.1:53 (DNS over TCP)
Connection H: UDP, 192.168.1.5:50006 → 10.0.0.1:53 (DNS over UDP)

Same IP and port, but different protocols—allowed because the 5-tuple differs.

Maximum Concurrent Connections:

The 5-tuple constraint has implications for scalability. Consider a server accepting connections on one IP:port:

• Source IPs are limited by client population
• Source ports are limited to ~65,535 per client IP
• Maximum connections from one client IP: ~65,535
• Maximum total connections: depends on total client IPs × ports

In practice, servers can handle millions of concurrent connections, but architects must understand these theoretical limits and plan for edge cases like proxy servers (single IP) or NAT pools.

Binding is the process of associating a socket with a local address. It's a critical step that determines which incoming connections or packets the socket will receive.

The bind() System Call:

int bind(int sockfd, const struct sockaddr *addr, socklen_t addrlen);

Bind assigns the socket sockfd the local address specified in addr. After binding, the socket is associated with that address for its lifetime (until closed).

When Binding is Required:

• Servers: Must bind to a known port so clients can connect to a predictable address
• UDP receivers: Must bind before receiving datagrams
• Multicast: Must bind to receive multicast group traffic

When Binding is Optional:

• TCP clients: The OS assigns an ephemeral port automatically on connect()
• UDP senders: The OS assigns an ephemeral port automatically on first send

The default behavior—one socket per address—is safe but sometimes too restrictive. Socket options enable controlled sharing of addresses:

SO_REUSEADDR:

This option allows binding to an address that's in TIME_WAIT state. When a TCP connection closes, the socket enters TIME_WAIT for ~60 seconds to ensure delayed packets don't confuse new connections. Without SO_REUSEADDR, a server restart within this window fails with EADDRINUSE.

int optval = 1;
setsockopt(sockfd, SOL_SOCKET, SO_REUSEADDR, &optval, sizeof(optval));

Important: SO_REUSEADDR is almost always set on server sockets. The alternative—waiting 60 seconds after every restart—is operationally unacceptable.

SO_REUSEPORT:

This option (Linux 3.9+, BSD) allows multiple sockets to bind to exactly the same address and port. The kernel distributes incoming connections across all listening sockets. Use cases:

• Multi-process servers: Each worker process has its own listening socket, avoiding the thundering herd problem of shared accept()
• Zero-downtime restarts: New server process binds before old one exits
• Load distribution: Kernel-level load balancing across processes

int optval = 1;
setsockopt(sockfd, SOL_SOCKET, SO_REUSEPORT, &optval, sizeof(optval));

Security Implications:

Address reuse has security implications. On some systems, SO_REUSEADDR allows a malicious process to bind to the same address as an existing service, potentially hijacking connections. Linux mitigates this by requiring both processes to set SO_REUSEADDR, but the behavior varies across operating systems.

Best Practices:

1. Always set SO_REUSEADDR on server sockets before bind()
2. Use SO_REUSEPORT deliberately—understand the load distribution semantics
3. Be aware of platform differences—test on target deployment environment
4. Consider security context—in multi-tenant environments, address reuse creates attack surfaces

Humans prefer domain names (www.example.com); sockets require IP addresses. The gap is bridged by address resolution—typically DNS (Domain Name System).

The getaddrinfo() Function:

Modern socket programming uses getaddrinfo() for protocol-independent address resolution:

int getaddrinfo(const char *node,      // Hostname or IP string
                const char *service,   // Port number or service name
                const struct addrinfo *hints,  // Desired address type
                struct addrinfo **res); // Results (linked list)

This function handles:

• DNS resolution (hostname → IP address)
• Service name resolution (/etc/services lookup)
• IPv4/IPv6 transparency
• Multiple address results (for redundancy)

Several IP addresses and port numbers have special meanings in socket programming:

Special IP Addresses (IPv4):

Special IP Addresses (IPv6):

Special Port Numbers:

Practical Implications:

1. Development vs. Production: Binding to 127.0.0.1 during development prevents accidental network exposure
2. Container Networking: INADDR_ANY is essential in containers where network namespaces isolate interfaces
3. Security: Never bind sensitive services to INADDR_ANY if they should only be locally accessible
4. Testing: Port 0 is invaluable for tests that need sockets but don't care about specific ports