Unix Network Programming Episode 18

Standard Internet Services

Notice that all are provided using both TCP and UDP and the port number is the same for both protocols.

Often these services are provided by the inetd daemon on Unix hosts. These standard services provide an easy testing facility using the standard Telnet client.

Notice that when we connect to the daytime server, the server performs the active close, while with the echo server, the client performs the active close. The end performing the active close is the end that goes through the TIME_WAIT state.
These “simple services” are often disabled by default on modern systems due to denial-of-service and other resource utilization attacks against them.

Protocol Usage by Common Internet Applications

The first two applications, ping and traceroute, are diagnostic applications that use ICMP. traceroute builds its own UDP packets to send and reads ICMP replies.

The three popular routing protocols demonstrate the variety of transport protocols used by routing protocols. OSPF uses IP directly, employing a raw socket, while RIP uses UDP and BGP uses TCP.

The next five are UDP-based applications, followed by seven TCP applications and four that use both UDP and TCP. The final five are IP telephony applications that use SCTP exclusively or optionally UDP, TCP, or SCTP.

Sockets Introduction

Introduction

We begin with socket address structures, which will be found in almost every example in the text. These structures can be passed in two directions: from the process to the kernel, and from the kernel to the process. The latter case is an example of a value-result argument, and we will encounter other examples of these arguments throughout the text.

The address conversion functions convert between a text representation of an address and the binary value that goes into a socket address structure. Most existing IPv4 code uses inet_addr and inet_ntoa, but two new functions, inet_pton and inet_ntop, handle both IPv4 and IPv6.

Socket Address Structures

Most socket functions require a pointer to a socket address structure as an argument. Each supported protocol suite defines its own socket address structure. The names of these structures begin with sockaddr_ and end with a unique suffix for each protocol suite.

IPv4 Socket Address Structure

An IPv4 socket address structure, commonly called an “Internet socket address structure,” is named sockaddr_in and is defined by including the <netinet/in.h> header.

struct in_addr {
	in_addr_t s_addr; /* 32-bit IPv4 address */
	/* network byte ordered */
};
struct sockaddr_in {
	uint8_t sin_len; /* length of structure (16) */
	sa_family_t sin_family; /* AF_INET */
	in_port_t sin_port; /* 16-bit TCP or UDP port number */
	/* network byte ordered */
	struct in_addr sin_addr; /* 32-bit IPv4 address */
	/* network byte ordered */
	char sin_zero[8]; /* unused */
};

The Internet (IPv4) socket address structure: sockaddr_in.

There are several points we need to make about socket address structures in general using this example:

• The length member, sin_len, was added with 4.3BSD-Reno, when support for the OSI protocols was added. Before this release, the first member was sin_family, which was historically an unsigned short. Not all vendors support a length field for socket address structures and the POSIX specification does not require this member. The datatype that we show, uint8_t, is typical, and POSIX-compliant systems provide datatypes of this form.
• Even if the length field is present, we need never set it and need never examine it, unless we are dealing with routing sockets (Chapter 18(See 9.7)). It is used within the kernel by the routines that deal with socket address structures from various protocol families (e.g., the routing table code).
• The POSIX specification requires only three members in the structure: sin_family, sin_addr, and sin_port. It is acceptable for a POSIX-compliant implementation to define additional structure members, and this is normal for an Internet socket address structure. Almost all implementations add the sin_zero member so that all socket address structures are at least 16 bytes in size.
• We show the POSIX datatypes for the s_addr, sin_family, and sin_port members. The in_addr_t datatype must be an unsigned integer type of at least 32 bits, in_port_t must be an unsigned integer type of at least 16 bits, and sa_family_t can be any unsigned integer type. The latter is normally an 8-bit unsigned integer if the implementation supports the length field, or an unsigned 16-bit integer if the length field is not supported. Figure 3.2 lists these three POSIX-defined datatypes, along with some other POSIX datatypes that we will encounter.
• You will also encounter the datatypes u_char, u_short, u_int, and u_long, which are all unsigned. The POSIX specification defines these with a note that they are obsolete. They are provided for backward compatibility.
• Both the IPv4 address and the TCP or UDP port number are always stored in the structure in network byte order. We must be cognizant of this when using these members. We will say more about the difference between host byte order and network byte order in Section 3.4(See 8.1.4).
• The 32-bit IPv4 address can be accessed in two different ways. For example, if serv is defined as an Internet socket address structure, then serv.sin_addr references the 32-bit IPv4 address as an in_addr structure, while serv.sin_addr.s_addr references the same 32-bit IPv4 address as an in_addr_t (typically an unsigned 32-bit integer). We must be certain that we are referencing the IPv4 address correctly, especially when it is used as an argument to a function, because compilers often pass structures differently from integers.
• The sin_zero member is unused, but we always set it to 0 when filling in one of these structures. By convention, we always set the entire structure to 0 before filling it in, not just the sin_zero member.
  Although most uses of the structure do not require that this member be 0, when binding a non-wildcard IPv4 address, this member must be 0 (pp. 731–732 of TCPv2).
• Socket address structures are used only on a given host: The structure itself is not communicated between different hosts, although certain fields (e.g., the IP address and port) are used for communication.