«  3.9. Extended Example: Bash-lite: A Simple Command-line Shell   ::   Contents   ::   4.2. The TCP/IP Internet Model  »

4.1. Networked Concurrency

Timeline of major CSF topics with Sockets and Networking highlighted

“The web is more a social creation than a technical one. I designed it for a social effect - to help people work together - and not as a technical toy.”

Tim Berners-Lee

Once processes on a single machine were able to exchange data, computer scientists turned their attention to bridging the gap between machines. The next step in the evolution of concurrency involved adapting the file abstraction to a network interface. Joel M. Winett defined the socket in RFC 147 (1971) as unique identifiers for transmitting data to the ARPA network, creating an instrumental abstraction that continues to serve as the basis of networked communications programming.

Decorative chapter objectives image

Chapter Objectives


In this chapter, we will address the following instructional objectives:

  • We will define the fundamental building blocks of the TCP/IP Internet model, including its structure as a layered architecture.
  • We will describe the key components and architectural structures of network applications.
  • We will examine how the socket API is used to implement network applications.
  • We will implement of basic features of three protocols (HTTP, DNS, DHCP) that demonstrate key features of TCP and UDP socket programming.

IPC provides a communication infrastructure that can be used in two very different ways. Architects of complex, interrelated applications can distribute the workload across processes to benefit from fault isolation guarantees, while maintaining a centralized means to coordinate the work. One example of this approach is a web browser that uses distinct processes for each tab opened; a plug-in crash in one tab would not affect any others. On the other hand, developers and users of simple applications may leverage IPC to chain these modules together to perform a more complex calculation. Linking multiple command-line processes together with a pipe illustrates this approach.

Both of these approaches benefit from a high degree of reliability, as all of the services are running on the same machine. For instance, if one process sends data through a message queue or pipe to another process, that data is unlikely to be lost by the kernel. Similarly, if two processes with similar privileges are both accessing a file on disk, it is unlikely that one of them will be able to read the file while the other cannot. Certainly, in these scenarios, misconfigurations or software errors make it possible for the communication to fail, but the system infrastructure itself is unlikely to cause such failures.

We can extend the goals and basic principles of IPC to networked communication between processes on different machines, but this extension does not maintain the same levels of reliability as local communication. That is, concurrent applications that are designed to run on top of networked computer systems—our focus is on the Internet in particular—commonly experience intermittent faults that cannot be attributed simply to misconfigurations or software errors. The network infrastructure itself introduces an element of volatility that applications must take into consideration. Fortunately, the network infrastructure provides services that can help to create reliable communication, if the application truly requires it.

In this chapter, we will introduce the general structure of the networked communication infrastructure used in the Internet. Our focus here is on the programming interface—the socket API—that software developers can use to communicate with processes running on different machines. We will also explore details of three common protocols that highlight key features of socket programming. In the next chapter, we will then focus on the network as a system itself.

«  3.9. Extended Example: Bash-lite: A Simple Command-line Shell   ::   Contents   ::   4.2. The TCP/IP Internet Model  »

Contact Us License