Linux Kernel Architecture

Chapter 12: Networks

12.3 Communication via Sockets

From the programmer’s view, external devices are simply regular files under Linux (andUnix)that

are accessed by normal read and write operations, as described in Chapter 8. This simplifies access to

resources because only a single, universal interface is needed.

The situation is a bit more complicated with network cards because the above scheme either cannot

be adopted at all or only with great difficulty. Network cards function in a totally different way from

normal block and character devices so that the typicalUnixmotto that ‘‘everything is a file‘‘ no longer

fully applies.^3 One reason is that many different communication protocols are used (in all layers) where

many options need to be specified in order to establish a connection — and this cannot be done when

device files are opened. Consequently, there are no entries for network cards in the/devdirectory.^4

Of course, the kernel must provide an interface that is as universal as possible to allow access to its

network functions. This problemis not Linux-specific and gave BSDUnixprogrammers headaches in

the 1980s. The solution they adopted — special structures calledsocketsthat are used as an interface for

network implementation — has now established itself as an industry standard. Sockets are defined in the

POSIX standard and are therefore also implemented by Linux.

Sockets are now used to define and set up network connections so that they can be accessed (particularly

by read and write operations) using the normal means of an inode. In the view of programmers, the

ultimate result of socket creation is a file descriptor that provides not only the whole range of standard

functions but also several enhanced functions. The interface used for the actual exchange of data is the

same for all protocols and address families.

When a socket is created, a distinction is made not only between address and protocol families but

also between stream-based and datagram-based communication. What is also important (with stream-

oriented sockets) is whether a socket is generated for a client or for a server program.

To illustrate the function of a socket from a user point of view, I include a short sample program to

demonstrate just a few of the network programmingoptions. Detailed descriptions are provided in

numerous specialized publications, [Ste00], for example.

12.3.1 Creating a Socket

Sockets can be used not only for IP connections with different transport protocols, but also for all other

address and protocol types supported by the kernel (e.g., IPX, Appletalk, localUnixsockets, DECNet,

and many other listed in<socket.h>). For this reason, it is essential to specify the desired combination

when generating a socket. Although, as a relic of the past, it is possible to select any combination of

partners from the address and protocol families, now only one protocol family is usually supported

for each address family, and it is only possible to differentiate between stream- and datagram-oriented

(^3) There are, however, severalUnixvariants that implement network connections directly by means of device files,/dev/tcp,for
example (see [Vah96]). From the application programmer’s point of view and from that of the kernel itself, this is far less elegant than
the socket method. Because the differences between network devices and normal devices are particularly evident when a connection
is opened, network operations in Linux are only implemented by means of file descriptors (that can be processed with normal file
methods) once a connection has been set up using the socket mechanism.
(^4) One exception is the TUN/TAP driver, which simulates a virtual network card in userspace and is therefore very useful for debug-
ging, for simulating network cards, or for setting up virtual tunnel connections. Because it does not communicate with any real
device in order to send or receive data, this job is done by a program that communicates with the kernel via/dev/tunXor
dev/tapX.