TCP/IP Sockets in C: Practical Guide for Programmers

TCP/IP Sockets in C\ Practical Guide for Programmers \ \ By Michael J. Donahoo Kenneth L. Calvert \ MORGAN KAUFMANN\ Copyright © 2009 Elsevier Inc.\ All right reserved.\ ISBN: 978-0-08-092321-5 \ \ \ Chapter One\ Introduction \ Today people use computers to make phone calls, watch TV, send instant messages to their friends, play games with other people, and buy most anything you can think of—from songs to automobiles. The ability of programs to communicate over the Internet makes all this possible. It's hard to say how many individual computers are now reachable over the Internet, but we can safely say that it is growing rapidly; it won't be long before the number is in the billions. Moreover, new applications are being developed every day. With the push for ever increasing bandwidth and access, the impact of the Internet will continue to grow for the forseeable future.\ How does a program communicate with another program over a network? The goal of this book is to start you on the road to understanding the answer to that question, in the context of the C programming language. For a long time, C was the language of choice for implementing network communication softward. Indeed, the application programming interface (API) known as Sockets was first developed in C.\ Before we delve into the details of sockets, however, it is worth taking a brief look at the big picture of networks and protocols to see where our code will fit in. Our goal here is not to teach you how networks and TCP/IP work—many fine texts are available for that purpose—but rather to introduce some basic concepts and terminology.\ 1.1 Networks, Packets, and Protocols\ A computer network consists of machines interconnected by communication channels. We call these machines hosts and routers. Hosts are computers that run applications such as your Web browser, your IM agent, or a file-sharing program. The application programs running on hosts are the real "users" of the network. Routers (also called gateways) are machines whose job is to relay, or forward, information from one communication channel to another. They may run programs but typically do not run application programs. For our purposes, a communication channel is a means of conveying sequences of bytes from one host to another; it may be a wired (e.g., Ethernet), a wireless (e.g., WiFi), or other connection.\ Routers are important simply because it is not practical to connect every host directly to every other host. Instead, a few hosts connect to a router, which connects to other routers, and so on to form the network. This arrangement lets each machine get by with a relatively small number of communication channels; most hosts need only one. Programs that exchange information over the network, however, do not interact directly with routers and generally remain blissfully unaware of their existence.\ By information we mean sequences of bytes that are constructed and interpreted by programs. In the context of computer networks, these byte sequences are generally called packets. A packet contains control information that the network uses to do its job and sometimes also includes user data. An example is information identifying the packet's destination. Routers use such control information to figure out how to forward each packet.\ A protocol is an agreement about the packets exchanged by communicating programs and what they mean. A protocol tells how packets are structured—for example, where the destination information is located in the packet and how big it is—as well as how the information is to be interpreted. A protocol is usually designed to solve a specific problem using given capabilities. For example, the HyperText Transfer Protocol (HTTP) solves the problem of transferring hypertext objects between servers, where they are stored or generated, and Web browsers that make them visible and useful to users. Instant messaging protocols solve the problem of enabling two or more users to exchange brief text messages.\ Implementing a useful network requires solving a large number of different problems. To keep things manageable and modular, different protocols are designed to solve different sets of problems. TCP/IP is one such collection of solutions, sometimes called a protocol suite. It happens to be the suite of protocols used in the Internet, but it can be used in stand-alone private networks as well. Henceforth when we talk about the network, we mean any network that uses the TCP/IP protocol suite. The main protocols in the TCP/IP suite are the Internet Protocol (IP), the Transmission Control Protocol (TCP), and the User Datagram Protocol (UDP).\ It turns out to be useful to organize protocols into layers; TCP/IP and virtually all other protocol suites are organized this way. Figure 1.1 shows the relationships among the protocols, applications, and the Sockets API in the hosts and routers, as well as the flow of data from one application (using TCP) to another. The boxes labeled TCP and IP represent implementations of those protocols. Such implementations typically reside in the operating system of a host. Applications access the services provided by UDP and TCP through the Sockets API, represented as a dashed line. The arrow depicts the flow of data from the application, through the TCP and IP implementations, through the network, and back up through the IP and TCP implementations at the other end.\ In TCP/IP, the bottom layer consists of the underlying communication channels—for example, Ethernet or dial-up modem connections. Those channels are used by the network layer, which deals with the problem of forwarding packets toward their destination (i.e., what routers do). The single-network layer protocol in the TCP/IP suite is the Internet Protocol; it solves the problem of making the sequence of channels and routers between any two hosts look like a single host-to-host channel.\ The Internet Protocol provides a datagram service: every packet is handled and delivered by the network independently, like letters or parcels sent via the postal system. To make this work, each IP packet has to contain the address of its destination, just as every package that you mail is addressed to somebody. (We'll say more about addresses shortly.) Although most delivery companies guarantee delivery of a package, IP is only a best-effort protocol: it attempts to deliver each packet, but it can (and occasionally does) lose, reorder, or duplicate packets in transit through the network.\ The layer above IP is called the transport layer. It offers a choice between two protocols: TCP and UDP. Each builds on the service provided by IP, but they do so in different ways to provide different kinds of transport, which are used by application protocols with different needs. TCP and UDP have one function in common: addressing. Recall that IP delivers packets to hosts; clearly, a finer granularity of addressing is needed to get a packet to a particular application program, perhaps one of many using the network on the same host. Both TCP and UDP use addresses, called port numbers, to identify applications within hosts. TCP and UDP are called end-to-end transport protocols because they carry data all the way from one program to another (whereas IP only carries data from one host to another).\ TCP is designed to detect and recover from the losses, duplications, and other errors that may occur in the host-to-host channel provided by IP. TCP provides a reliable byte-stream channel, so that applications do not have to deal with these problems. It is a connection-oriented protocol: before using it to communicate, two programs must first establish a TCP connection, which involves completing an exchange of handshake messages between the TCP implementations on the two communicating computers. Using TCP is also similar in many ways to file input/output (I/O). In fact, a file that is written by one program and read by another is a reasonable model of communication over a TCP connection. UDP, on the other hand, does not attempt to recover from errors experienced by IP; it simply extends the IP best-effort datagram service so that it works between application programs instead of between hosts. Thus, applications that use UDP must be prepared to deal with losses, reordering, and so on.\ 1.2 About Addresses\ When you mail a letter, you provide the address of the recipient in a form that the postal service can understand. Before you can talk to someone on the phone, you must supply a phone number to the telephone system. In a similar way, before a program can communicate with another program, it must tell the network something to identify the other program. In TCP/IP, it takes two pieces of information to identify a particular program: an Internet address, used by IP, and a port number, the additional address interpreted by the transport protocol (TCP or UDP).\ Internet addresses are binary numbers. They come in two flavors, corresponding to the two versions of the Internet Protocol that have been standardized. The most common is version 4 (IPv4,); the other is version 6 (IPv6,), which is just beginning to be deployed. IPv4 addresses are 32 bits long; because this is only enough to identify about 4 billion distinct destinations, they are not really big enough for today's Internet. (That may seem like a lot, but because of the way they are allocated, many are wasted. More than half of the total IPv4 address space has already been allocated.) For that reason, IPv6 was introduced. IPv6 addresses are 128 bits long.\ 1.2.1 Writing Down IP Addresses\ In representing Internet addresses for human consumption (as opposed to using them inside programs), different conventions are used for the two versions of IP. IPv4 addresses are conventionally written as a group of four decimal numbers separated by periods (e.g., 10.1.2.3); this is called the dotted-quad notation. The four numbers in a dotted-quad string represent the contents of the four bytes of the Internet address—thus, each is a number between 0 and 255.\ The 16 bytes of an IPv6 address, on the other hand, by convention are represented as groups of hexadecimal digits, separated by colons (e.g., 2000:fdb8:0000:0000:0001:00ab:853c: 39a1). Each group of digits represents 2 bytes of the address; leading zeros may be omitted, so the fifth and sixth groups in the foregoing example might be rendered as just :1:ab:. Also, one sequence of groups that contains only zeros may be omitted altogether (while leaving the colons that would separate them from the rest of the address). So the example above could be written as 2000:fdb8::1:00ab:853c:39a1.\ Technically, each Internet address refers to the connection between a host and an underlying communication channel—in other words, a network interface. A host may have several interfaces; it is not uncommon, for example, for a host to have connections to both wired (Ethernet) and wireless (WiFi) networks. Because each such network connection belongs to a single host, an Internet address identifies a host as well as its connection to the network. However, the converse is not true, because a single host can have multiple interfaces, and each interface can have multiple addresses. (In fact, the same interface can have both IPv4 and IPv6 addresses.)\ 1.2.2 Dealing with Two Versions\ When the first edition of this book was written, IPv6 was not widely supported. Today most systems are capable of supporting IPv6 "out of the box." To smooth the transition from IPv4 to IPv6, most systems are dual-stack, simultaneously supporting both IPv4 and IPv6. In such systems, each network interface (channel connection) may have at least one IPv4 address and one IPv6 address.\ The existence of two versions of IP complicates life for the socket programmer. In general, you will need to choose either IPv4 or IPv6 as the underlying protocol when you create a socket to communicate. So how can you write an application that works with both versions? Fortunately, dual-stack systems handle interoperability by supporting both protocol versions and allowing IPv6 sockets to communicate with either IPv4 or IPv6 applications. Of course, IPv4 and IPv6 addresses are quite different; however, IPv4 addresses can be mapped into IPv6 addresses using IPv4 mapped addresses. An IPv4 mapped address is formed by prefixing the four bytes in the IPv4 address with ::fff. For example, the IPv4 mapped address for 132.3.23.7 is ::ffff:132.3.23.7. To aid in human readability, the last four bytes are typically written in dotted-quad notation. We discuss protocol interoperability in greater detail in Chapter 3.\ Unfortunately, having an IPv6 Internet address is not sufficient to enable you to communicate with every other IPv6-enabled host across the Internet. To do that, you must also arrange with your Internet Service Provider (ISP) to provide IPv6 forwarding service.\ (Continues...)\ \ \ \ \ Excerpted from TCP/IP Sockets in C by Michael J. Donahoo Kenneth L. Calvert Copyright © 2009 by Elsevier Inc. . Excerpted by permission of MORGAN KAUFMANN. All rights reserved. No part of this excerpt may be reproduced or reprinted without permission in writing from the publisher.\ Excerpts are provided by Dial-A-Book Inc. solely for the personal use of visitors to this web site. \ \

Preface to the Second Edition ix1 Introduction 11.1 Networks, Packets, and Protocols 11.2 About Addresses 41.2.1 Writing Down IP Addresses 41.2.2 Dealing with Two Versions 51.2.3 Port Numbers 51.2.4 Special Addresses 61.3 About Names 71.4 Clients and Servers 71.5 What Is a Socket? 82 Basic TCP Sockets 112.1 IPv4 TCP Client 112.2 IPv4 TCP Server 172.3 Creating and Destroying Sockets 222.4 Specifying Addresses 232.4.1 Generic Addresses 232.4.2 IPv4 Addresses 242.4.3 IPv4 Addresses 242.4.4 Generic Address Storage 252.4.5 Binary/String Address Conversion 262.4.6 Getting a Socket's Associated Addresses 262.5 Connecting a Socket 272.6 Binding to an Address 272.7 Handling Incoming Connections 282.8 Communication 302.9 Using IPv6 303 Of Names and Address Families 353.1 Mapping Names to Numbers 353.1.1 Accessing the Name Service 363.1.2 Details, Details 403.2 Writing Address-Generic Code 413.2.1 Generic TCP Client 433.2.2 Generic TCP Server 463.2.3 IPv4-IPv6 Interoperation 493.3 Getting Names from Numbers 504 Using UDP Sockets 534.1 UDP Client 544.2 UDP Server 574.3 Sending and Receiving with UDP Sockets 604.4 Connecting a UDP Socket 615 Sending and Receiving Data 635.1 Encoding Integers 645.1.1 Sizes of Integers 645.1.2 Byte Ordering 665.1.3 Signedness and Sign Extension 675.1.4 Encoding Integers by Hand 685.1.5 Wrapping TCP Sockets in Streams 715.1.6 Structure Overlays: Alignment and Padding 735.1.7 Strings and Text 765.1.8 Bit-Diddling: Encoding Booleans 785.2 Constructing, Framing, and Parsing Messages 795.2.1 Framing 865.2.2Text-Based Message Encoding 915.2.3 Binary Message Encoding 945.2.4 Putting It All Together 965.3 Wrapping Up 976 Beyond Basic Socket Programming 996.1 Socket Options 996.2 Signals 1006.3 Nonblocking I/O 1066.3.1 Nonblocking Sockets 1076.3.2 Asynchronous I/O 1086.3.3 Timeouts 1126.4 Multitasking 1166.4.1 Per-Client Processes 1176.4.2 Per-Client Thread 1236.4.3 Constrained Multitasking 1266.5 Multiplexing 1286.6 Multiple Recipients 1336.6.1 Broadcast 1346.6.2 Multicast 1376.6.3 Broadcast vs. Multicast 1427 Under the Hood 1437.1 Buffering and TCP 1457.2 Deadlock Danger 1487.3 Performance Implications 1497.4 TCP Socket Life Cycle 1507.4.1 Connecting 1507.4.2 Closing a TCP Connection 1547.5 Demultiplexing Demystified 1588 Socket Programming in C++ 1618.1 PracticalSocket Library Overview 1628.2 Plus One Service 1648.2.1 Plus One Server 1648.2.2 Plus One Client 1668.2.3 Running Server and Client 1688.3 Survey Service 1688.3.1 Survey Support Functions 1698.3.2 Survey Server 1728.3.3 Survey Client 1768.3.4 Running Server and Client 1788.4 Survey Service, Mark 2 1788.4.1 Socket Address Support 1798.4.2 Socket Iostream Interface 1808.4.3 Enhanced Survey Server 1818.4.4 Enhanced Survey Client 1868.4.5 Administrative Client 1878.4.6 Running Server and Clients 188References 191Index 193

\ From the Publisher"This book fills a void in the area of networking education. The presentation is easily accessible to students, with lots of code examples. It will be an excellent companion to traditional networking textbooks for use in undergraduate and introductory graduate courses." --Ellen W. Zegura, Georgia Institute of Technology \ "This is the best, all-in-one socket book I have read and yet it doesn't come with the unnecessary overhead of many other books. It is loaded with very useful examples and it can be used as a socket API reference as well. In a word, it is a very well written book that has everything practitioners need." --Steve Bernier, Communications Research Center\ \