.. _SocketsOverview:

.. raw:: html

   <script>ODSA.SETTINGS.DISP_MOD_COMP = true;ODSA.SETTINGS.MODULE_NAME = "SocketsOverview";ODSA.SETTINGS.MODULE_LONG_NAME = "Networked Concurrency";ODSA.SETTINGS.MODULE_CHAPTER = "Networked Concurrency"; ODSA.SETTINGS.BUILD_DATE = "2021-06-01 12:51:47"; ODSA.SETTINGS.BUILD_CMAP = false;JSAV_OPTIONS['lang']='en';JSAV_EXERCISE_OPTIONS['code']='java';</script>


.. |--| unicode:: U+2013   .. en dash
.. |---| unicode:: U+2014  .. em dash, trimming surrounding whitespace
   :trim:


.. This file is part of the OpenCSF eTextbook project. It was
.. auto-generated by scripts from the OpenDSA eTextbook project.
.. See https://OpenCSF.org for more details. OpenCSF is distributed
.. under a Creative Commons Attribution-NonCommercial 4.0 International
.. License (see http://creativecommons.org/licenses/by-nc/4.0/),
.. Copyright (c) 2019-2021 by Michael S. Kirkpatrick. OpenDSA is
.. distributed under an MIT open source license, Copyright (c) 2012-2021
.. by the OpenDSA Project Contributors.

.. avmetadata::
   :author: Michael S. Kirkpatrick
   :requires:
   :satisfies: Networked Concurrency Overview
   :topic: Sockets, Networks

Networked Concurrency
=====================

.. figure:: Images/CSF-Timeline.4.png
   :align: center
   :width: 90%
   :figwidth: 100%
   :alt: Timeline of major CSF topics with Sockets and Networking highlighted

.. raw:: html

    <blockquote class="blockquote text-center">
        <p>“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.”
        <footer class="blockquote-footer">Tim Berners-Lee</footer>
    </blockquote>

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.

.. topic:: Chapter Objectives

   .. figure:: Images/CSF-Images-Objectives.png
      :align: left
      :figwidth: 5%
      :width: 100%
      :alt: Decorative chapter objectives image

   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 :term:`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
:term:`socket` API—that software developers can use to communicate with processes running on
different machines. We will also explore details of three common :term:`protocols <protocol>` that
highlight key features of socket programming. In the next chapter, we will then focus on the network
as a system itself.

