| Berkeley sockets are part of an application programming interface (API) that specifies the data structures and function calls that interact with the operating system's network subsystem. The name derives from the origins of the API in release 4.2 of the Berkeley Standard Distribution (4.2BSD) of UNIX. Berkeley sockets act at the transport layer: They help get the data where it's going, but have nothing to say about the content of the data. Berkeley sockets are part of an API, not a specific protocol, which defines how the programmer interacts with an idealized network. Although strongly associated with the TCP/IP network protocol for which the API was first designed, the Berkeley sockets API is generic enough to support other types of network, such as Novell Netware, Windows NT networking, and Appletalk. Perl provides full support for Berkeley sockets on most of the platforms it runs on. On certain platforms such as the Windows and Macintosh ports, extension modules also give you access to the non-Berkeley APIs native to those machines. However, if you're interested in writing portable applications you'll probably want to stick to the Berkeley API. The Anatomy of a Socket A socket is an endpoint for communications, a portal to the outside world that we can use to send outgoing messages to other processes, and to receive incoming traffic from processes interested in sending messages to us. To create a socket, we need to provide the system with a minimum of three pieces of information. The Socket's Domain The domain defines the family of networking protocols and addressing schemes that the socket will support. The domain is selected from a small number of integer constants defined by the operating system and exported by Perl's Socket module. There are only two common domains (see Table 3.1). AF_INET is used for TCP/IP networking. Sockets in this domain use IP addresses and port numbers as their addressing scheme (more on this later). AF_UNIX is used only for interprocess communication within a single host. Addresses in this domain are file pathnames. The name AF_UNIX is unfairly UNIX-specific; it's possible for non-UNIX systems to implement it. For this reason, POSIX has tried to rename this constant AF_LOCAL , although few systems have followed suit. Table 3.1. Common Socket Domains | Constant | Description | | AF_INET | The Internet protocols | | AF_UNIX | Networking within a single host | In addition to these domains, there are many others including AF_APPLETALK , AF_IPX , and AF_X25 , each corresponding to a particular addressing scheme. AF_INET6 , corresponding to the long addresses of TCP/IP version 6, will become important in the future, but is not yet supported by Perl. The AF_ prefix stands for "address family." In addition, there is a series of "protocol family" constants starting with the PF_ prefix. For example, there is a PF_INET constant that corresponds to AF_INET . These constants evaluate to the same value and can, in fact, be used interchangeably. The distinction between them is a historical artifact, and you'll find that published code sometimes uses the one and sometimes the other. The Socket's Type The socket type identifies the basic properties of socket communications. As explained more fully in the next section, sockets can be either a "stream" type, in which case data is sent through a socket in a continuous stream (like reading or writing to a file, for example), or a "datagram" type, in which case data is sent and received in discrete packages. The type is controlled by an operating-system-defined constant that evaluates to a small integer. Common constants exported by Socket are shown in Table 3.2. Table 3.2. Constants Exported by Socket | Constant | Description | | SOCK_STREAM | A continuous stream of data | | SOCK_DGRAM | Individual packets of data | | SOCK_RAW | Access to internal protocols and interfaces | Perl fully supports the SOCK_STREAM and SOCK_DGRAM socket types. SOCK_RAW is supported through an add-on module named Net::Raw. The Socket's Protocol For a given socket domain and type, there may be one or several protocols that implement the desired behavior. Like the domain and socket type, the protocol is a small integer. However, the protocol numbers are not available as constants, but instead must be looked up at run time using the Perl getprotobyname () function. Some of the protocols are listed in Table 3.3. Table 3.3. Some Socket Protocols | Protocol | Description | | tcp | Transmission Control Protocol for stream sockets | | udp | User Datagram Protocol for datagram sockets | | icmp | Internet Control Message Protocol | | raw | Creates IP packets manually | The TCP and UDP protocols are supported directly by the Perl sockets API. You can get access to the ICMP and raw protocols via the Net::ICMP and Net::Raw third-party modules, but we do not discuss them in this book (it would be possible, but probably not sensible , to reimplement TCP in Perl using raw packets). Generally there exists a single protocol to support a given domain and type. When creating a socket, you must be careful to set the domain and socket type to match the protocol you've selected. The possible combinations are summarized in Table 3.4. Table 3.4. Allowed Combinations of Socket Type and Protocol in the INET and UNIX Domains | Domain | Type | Protocol | | AF_INET | SOCK_STREAM | tcp | | AF_INET | SOCK_DGRAM | udp | | AF_UNIX | SOCK_STREAM | PF_UNSPEC | | AF_UNIX | SOCK_DGRAM | PF_UNSPEC | The allowed combinations of socket domain, type, and protocol are few. SOCK_STREAM goes with TCP, and SOCK_DGRAM goes with UDP. Also notice that the AF_UNIX address family doesn't use a named protocol, but a pseudoprotocol named PF_UNSPEC (for "unspecified"). The Perl object-oriented IO::Socket module (discussed in Chapter 5) can fill in the correct socket type and protocol automatically when provided with partial information. Datagram Sockets Datagram-type sockets provide for the transmission of connectionless, unreliable, unsequenced messages. The UDP is the chief datagram-style protocol used by the Internet protocol family. As the diagram in Figure 3.2 shows, datagram services resemble the postal system. Like a letter or a telegram, each datagram in the system carries its destination address, its return address, and a certain amount of data. The Internet protocols will make the best effort to get the datagram delivered to its destination. Figure 3.2. Datagram sockets provide connectionless, unreliable, unsequenced transmission of message  There is no long- term relationship between the sending socket and the recipient socket: A client can send a datagram off to one server, then immediately turn around and send a datagram to another server using the same socket. But the connectionless nature of UDP comes at a price. Like certain countries ' postal systems, it is very possible for a datagram to get "lost in the mail." A client cannot know whether a server has received its message until it receives an acknowledgment in reply. Even then, it can't know for sure that a message was lost, because the server might have received the original message and the acknowledgment got lost! Datagrams are neither synchronized nor flow controlled. If you send a set of datagrams out in a particular order, they might not arrive in that order. Because of the vagaries of the Internet, the first datagram may go by one route, and the second one may take a different path . If the second route is faster than the first one, the two datagrams may arrive in the opposite order from which they were sent. It is also possible for a datagram to get duplicated in transit, resulting in the same message being received twice. Because of the connectionless nature of datagrams, there is no flow control between the sender and the recipient. If the sender transmits datagrams faster than the recipient can process them, the recipient has no way to signal the sender to slow down, and will eventually start to discard packets. Although a datagram's delivery is not reliable, its contents are. Modern implementations of UDP provide each datagram with a checksum that ensures that its data portion is not corrupted in transit. Stream Sockets The other major paradigm is stream sockets, implemented in the Internet domain as the TCP protocol. Stream sockets provide sequenced , reliable bidirectional communications via byte-oriented streams. As depicted in Figure 3.3, stream sockets resemble a telephone conversation. Clients connect to servers using their address, the two exchange data for a period of time, and then one of the pair breaks off the connection. Figure 3.3. Stream sockets provide sequenced, reliable, bidirectional communications  Reading and writing to stream sockets is a lot like reading and writing to a file. There are no arbitrary size limits or record boundaries, although you can impose a record-oriented structure on the stream if you like. Because stream sockets are sequenced and reliable, you can write a series of bytes into a socket secure in the knowledge that they will emerge at the other end in the correct order, provided that they emerge at all ("reliable" does not mean immune to network errors). TCP also implements flow control. Unlike UDP, where the danger of filling the data-receiving buffer is very real, TCP automatically signals the sending host to suspend transmission temporarily when the reading host is falling behind, and to resume sending data when the reading host is again ready. This flow control happens behind the scenes and is ordinarily invisible. If you have ever used the Perl open(FH, " command ") syntax to open up a pipe to an external program, you will find that working with stream sockets is not much different. The major visible difference is that, unlike pipes, stream sockets are bidirectional. Although it looks and acts like a continuous byte stream, the TCP protocol is actually implemented on top of a datagram-style service, in this case the low-level IP protocol. IP packets are just as unreliable as UDP datagrams, so behind the scenes TCP is responsible for keeping track of packet sequence numbers, acknowledging received packets, and retransmitting lost packets. Datagram versus Stream Sockets With all its reliability problems, you might wonder why anyone uses UDP. The answer is that most client/server programs on the Internet use TCP stream sockets instead. In most cases, TCP is the right solution for you, too. There are some circumstances, however, in which UDP might be a better choice. For example, time servers use UDP datagrams to transmit the time of day to clients who use the information for clock synchronization. If a datagram disappears in transit, it's neither necessary nor desirable to retransmit it because by the time it arrives it will no longer be relevant. UDP is also preferred when the interaction between one host and the other is very short. The length of time to set up and take down a TCP connection is about eightfold greater than the exchange of a single byte of data via UDP (for details, see [Stevens 1996]). If relatively small amounts of data are being exchanged, the TCP setup time will dominate performance. Even after a TCP connection is established, each transmitted byte consumes more bandwidth than UDP because of the additional overhead for ensuring reliability. Another common scenario occurs when a host must send the same data to many places; for example, it wants to transmit a video stream to multiple viewers . The overhead to set up and manage a large number of TCP connections can quickly exhaust operating system resources, because a different socket must be used for each connection. In contrast, sending a series of UDP datagrams is much more sparing of resources. The same socket can be reused to send datagrams to many hosts . Whereas TCP is always a one-to-one connection, UDP also allows one-to-many and many-to-many transmissions. At one end of the spectrum, you can address a UDP datagram to the "broadcast address," broadcasting a message to all listening hosts on the local area network. At the other end of the spectrum, you can target a message to a predefined group of hosts using the "multicast" facility of modern IP implementations. These advanced features are covered in Chapters 20 and 21. The Internet's DNS is a common example of a UDP-based service. It is responsible for translating hostnames into IP addresses, and vice versa, using a loose-knit network of DNS servers. If a client does not get a response from a DNS server, it just retransmits its request. The overhead of an occasional lost datagram outweighs the overhead of setting up a new TCP connection for each request. Other common examples of UDP services include Sun's Network File System (NFS) and the Trivial File Transfer Protocol (TFTP). The latter is used by diskless workstations during boot in order to load their operating system over the network. UDP was originally chosen for this purpose because its implementation is relatively small. Therefore, UDP fit more easily into the limited ROM space available to workstations at the time the protocol was designed. The TCP/IP protocol suite is described well in [Stevens 1994, Wright and Stevens 1995, and Stevens 1996], as well as in RFC 1180, A TCP/IP Tutorial . | 
