491 lines
No EOL
38 KiB
HTML
491 lines
No EOL
38 KiB
HTML
|
||
<!DOCTYPE html>
|
||
|
||
|
||
|
||
|
||
<html lang="en">
|
||
<head>
|
||
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
|
||
|
||
<title>4.3. Network Applications and Protocols — Computer Systems Fundamentals</title>
|
||
|
||
<link rel="stylesheet" href="_static/css/bootstrap.min.css" integrity="sha384-ggOyR0iXCbMQv3Xipma34MD+dH/1fQ784/j6cY/iJTQUOhcWr7x9JvoRxT2MZw1T" crossorigin="anonymous" />
|
||
<link rel="stylesheet" href="_static/css/pygments.css" type="text/css" />
|
||
<link rel="stylesheet" href="_static/css/normalize.css" type="text/css" />
|
||
<link rel="stylesheet" href="../../../JSAV/css/JSAV.css" type="text/css" />
|
||
<link rel="stylesheet" href="../../../lib/odsaMOD-min.css" type="text/css" />
|
||
<link rel="stylesheet" href="_static/css/jquery-1.11.4-smoothness-ui.css" type="text/css" />
|
||
<link rel="stylesheet" href="../../../lib/odsaStyle-min.css" type="text/css" />
|
||
<link rel="stylesheet" href="_static/css/csf.css" type="text/css" />
|
||
|
||
<style>
|
||
.underline { text-decoration: underline; }
|
||
</style>
|
||
|
||
<script type="text/javascript">
|
||
var DOCUMENTATION_OPTIONS = {
|
||
URL_ROOT: './',
|
||
VERSION: '0.4.1',
|
||
COLLAPSE_INDEX: false,
|
||
FILE_SUFFIX: '.html',
|
||
HAS_SOURCE: true
|
||
};
|
||
</script>
|
||
|
||
<script type="text/x-mathjax-config">
|
||
MathJax.Hub.Config({
|
||
tex2jax: {
|
||
inlineMath: [['$','$'], ['\\(','\\)']],
|
||
displayMath: [ ['$$','$$'], ["\\[","\\]"] ],
|
||
processEscapes: true
|
||
},
|
||
"HTML-CSS": {
|
||
scale: "80"
|
||
}
|
||
});
|
||
</script>
|
||
<link rel="shortcut icon" href="_static/favicon.ico"/>
|
||
<link rel="index" title="Index" href="genindex.html" />
|
||
<link rel="search" title="Search" href="search.html" />
|
||
<link rel="index" title="Computer Systems Fundamentals" href="index.html" />
|
||
<link rel="next" title="4. The Socket Interface" href="Sockets.html" />
|
||
<link rel="prev" title="2. The TCP/IP Internet Model" href="FiveLayer.html" />
|
||
|
||
</head><body>
|
||
|
||
<nav class="navbar navbar-expand-md navbar-dark navbar-custom fixed-top">
|
||
|
||
<a class="navbar-brand py-0" href="index.html"><img src="_static/CSF-Logo-Square-Text.png" alt="OpenCSF Logo" height="40em" class="py-1 px-2 mb-0 align-center rounded-lg bg-white" /></a>
|
||
<!-- Show a navbar toggler on mobile -->
|
||
<button class="navbar-toggler" type="button" data-toggle="collapse" data-target="#defaultNavbars" aria-controls="defaultNavbars" aria-expanded="false" aria-label="Toggle navigation">
|
||
<span class="navbar-toggler-icon"></span>
|
||
</button>
|
||
<div class="collapse navbar-collapse" id="defaultNavbars">
|
||
<ul class="navbar-nav mr-auto">
|
||
<li class="nav-item dropdown">
|
||
<a class="nav-link dropdown-toggle jmu-gold rounded" href="NetApps.html#" id="navbarDropdownChapters" role="button" data-toggle="dropdown" aria-haspopup="true" aria-expanded="false">Contents</a>
|
||
<div class="dropdown-menu scrollable-menu" role="menu" aria-labelledby="navbarDropdownChapters">
|
||
<a class="dropdown-item" tabindex="-1" href="NetApps.html#"><b>Chapter 1</b></a>
|
||
<a class="dropdown-item" href="IntroConcSysOverview.html"> 1.1. Introduction to Concurrent Systems</a>
|
||
<a class="dropdown-item" href="SysAndModels.html"> 1.2. Systems and Models</a>
|
||
<a class="dropdown-item" href="Themes.html"> 1.3. Themes and Guiding Principles</a>
|
||
<a class="dropdown-item" href="Architectures.html"> 1.4. System Architectures</a>
|
||
<a class="dropdown-item" href="StateModels.html"> 1.5. State Models in UML</a>
|
||
<a class="dropdown-item" href="SequenceModels.html"> 1.6. Sequence Models in UML</a>
|
||
<a class="dropdown-item" href="StateModelImplementation.html"> 1.7. Extended Example: State Model Implementation</a>
|
||
<div class="dropdown-divider"></div>
|
||
<a class="dropdown-item disabled"><b>Chapter 2</b></a>
|
||
<a class="dropdown-item" href="ProcessesOverview.html"> 2.1. Processes and OS Basics</a>
|
||
<a class="dropdown-item" href="Multiprogramming.html"> 2.2. Processes and Multiprogramming</a>
|
||
<a class="dropdown-item" href="KernelMechanics.html"> 2.3. Kernel Mechanics</a>
|
||
<a class="dropdown-item" href="Syscall.html"> 2.4. System Call Interface</a>
|
||
<a class="dropdown-item" href="ProcessCycle.html"> 2.5. Process Life Cycle</a>
|
||
<a class="dropdown-item" href="UnixFile.html"> 2.6. The UNIX File Abstraction</a>
|
||
<a class="dropdown-item" href="EventsSignals.html"> 2.7. Events and Signals</a>
|
||
<a class="dropdown-item" href="Extended2Processes.html"> 2.8. Extended Example: Listing Files with Processes</a>
|
||
<div class="dropdown-divider"></div>
|
||
<a class="dropdown-item disabled"><b>Chapter 3</b></a>
|
||
<a class="dropdown-item" href="IPCOverview.html"> 3.1. Concurrency with IPC</a>
|
||
<a class="dropdown-item" href="IPCModels.html"> 3.2. IPC Models</a>
|
||
<a class="dropdown-item" href="Pipes.html"> 3.3. Pipes and FIFOs</a>
|
||
<a class="dropdown-item" href="MMap.html"> 3.4. Shared Memory With Memory-mapped Files</a>
|
||
<a class="dropdown-item" href="POSIXvSysV.html"> 3.5. POSIX vs. System V IPC</a>
|
||
<a class="dropdown-item" href="MQueues.html"> 3.6. Message Passing With Message Queues</a>
|
||
<a class="dropdown-item" href="ShMem.html"> 3.7. Shared Memory</a>
|
||
<a class="dropdown-item" href="IPCSems.html"> 3.8. Semaphores</a>
|
||
<a class="dropdown-item" href="Extended3Bash.html"> 3.9. Extended Example: Bash-lite: A Simple Command-line Shell</a>
|
||
<div class="dropdown-divider"></div>
|
||
<a class="dropdown-item disabled"><b>Chapter 4</b></a>
|
||
<a class="dropdown-item" href="SocketsOverview.html"> 4.1. Networked Concurrency</a>
|
||
<a class="dropdown-item" href="FiveLayer.html"> 4.2. The TCP/IP Internet Model</a>
|
||
<a class="dropdown-item" href="NetApps.html"> 4.3. Network Applications and Protocols</a>
|
||
<a class="dropdown-item" href="Sockets.html"> 4.4. The Socket Interface</a>
|
||
<a class="dropdown-item" href="TCPSockets.html"> 4.5. TCP Socket Programming: HTTP</a>
|
||
<a class="dropdown-item" href="UDPSockets.html"> 4.6. UDP Socket Programming: DNS</a>
|
||
<a class="dropdown-item" href="AppBroadcast.html"> 4.7. Application-Layer Broadcasting: DHCP</a>
|
||
<a class="dropdown-item" href="Extended4CGI.html"> 4.8. Extended Example: CGI Web Server</a>
|
||
<div class="dropdown-divider"></div>
|
||
<a class="dropdown-item disabled"><b>Chapter 5</b></a>
|
||
<a class="dropdown-item" href="InternetOverview.html"> 5.1. The Internet and Connectivity</a>
|
||
<a class="dropdown-item" href="AppLayer.html"> 5.2. Application Layer: Overlay Networks</a>
|
||
<a class="dropdown-item" href="TransLayer.html"> 5.3. Transport Layer</a>
|
||
<a class="dropdown-item" href="NetSec.html"> 5.4. Network Security Fundamentals</a>
|
||
<a class="dropdown-item" href="NetLayer.html"> 5.5. Network Layer: IP</a>
|
||
<a class="dropdown-item" href="LinkLayer.html"> 5.6. Link Layer</a>
|
||
<a class="dropdown-item" href="Wireless.html"> 5.7. Wireless Connectivity: Wi-Fi, Bluetooth, and Zigbee</a>
|
||
<a class="dropdown-item" href="Extended5DNS.html"> 5.8. Extended Example: DNS client</a>
|
||
<div class="dropdown-divider"></div>
|
||
<a class="dropdown-item disabled"><b>Chapter 6</b></a>
|
||
<a class="dropdown-item" href="ThreadsOverview.html"> 6.1. Concurrency with Multithreading</a>
|
||
<a class="dropdown-item" href="ProcVThreads.html"> 6.2. Processes vs. Threads</a>
|
||
<a class="dropdown-item" href="RaceConditions.html"> 6.3. Race Conditions and Critical Sections</a>
|
||
<a class="dropdown-item" href="POSIXThreads.html"> 6.4. POSIX Thread Library</a>
|
||
<a class="dropdown-item" href="ThreadArgs.html"> 6.5. Thread Arguments and Return Values</a>
|
||
<a class="dropdown-item" href="ImplicitThreads.html"> 6.6. Implicit Threading and Language-based Threads</a>
|
||
<a class="dropdown-item" href="Extended6Input.html"> 6.7. Extended Example: Keyboard Input Listener</a>
|
||
<a class="dropdown-item" href="Extended6Primes.html"> 6.8. Extended Example: Concurrent Prime Number Search</a>
|
||
<div class="dropdown-divider"></div>
|
||
<a class="dropdown-item disabled"><b>Chapter 7</b></a>
|
||
<a class="dropdown-item" href="SynchOverview.html"> 7.1. Synchronization Primitives</a>
|
||
<a class="dropdown-item" href="CritSect.html"> 7.2. Critical Sections and Peterson's Solution</a>
|
||
<a class="dropdown-item" href="Locks.html"> 7.3. Locks</a>
|
||
<a class="dropdown-item" href="Semaphores.html"> 7.4. Semaphores</a>
|
||
<a class="dropdown-item" href="Barriers.html"> 7.5. Barriers</a>
|
||
<a class="dropdown-item" href="Condvars.html"> 7.6. Condition Variables</a>
|
||
<a class="dropdown-item" href="Deadlock.html"> 7.7. Deadlock</a>
|
||
<a class="dropdown-item" href="Extended7Events.html"> 7.8. Extended Example: Event Log File</a>
|
||
<div class="dropdown-divider"></div>
|
||
<a class="dropdown-item disabled"><b>Chapter 8</b></a>
|
||
<a class="dropdown-item" href="SynchProblemsOverview.html"> 8.1. Synchronization Patterns and Problems</a>
|
||
<a class="dropdown-item" href="SynchDesign.html"> 8.2. Basic Synchronization Design Patterns</a>
|
||
<a class="dropdown-item" href="ProdCons.html"> 8.3. Producer-Consumer Problem</a>
|
||
<a class="dropdown-item" href="ReadWrite.html"> 8.4. Readers-Writers Problem</a>
|
||
<a class="dropdown-item" href="DiningPhil.html"> 8.5. Dining Philosophers Problem and Deadlock</a>
|
||
<a class="dropdown-item" href="CigSmokers.html"> 8.6. Cigarette Smokers Problem and the Limits of Semaphores and Locks</a>
|
||
<a class="dropdown-item" href="Extended8ModExp.html"> 8.7. Extended Example: Parallel Modular Exponentiation</a>
|
||
<div class="dropdown-divider"></div>
|
||
<a class="dropdown-item disabled"><b>Chapter 9</b></a>
|
||
<a class="dropdown-item" href="ParallelDistributedOverview.html"> 9.1. Parallel and Distributed Systems</a>
|
||
<a class="dropdown-item" href="ParVConc.html"> 9.2. Parallelism vs. Concurrency</a>
|
||
<a class="dropdown-item" href="ParallelDesign.html"> 9.3. Parallel Design Patterns</a>
|
||
<a class="dropdown-item" href="Scaling.html"> 9.4. Limits of Parallelism and Scaling</a>
|
||
<a class="dropdown-item" href="DistTiming.html"> 9.5. Timing in Distributed Environments</a>
|
||
<a class="dropdown-item" href="DistDataStorage.html"> 9.6. Reliable Data Storage and Location</a>
|
||
<a class="dropdown-item" href="DistConsensus.html"> 9.7. Consensus in Distributed Systems</a>
|
||
<a class="dropdown-item" href="Extended9Blockchain.html"> 9.8. Extended Example: Blockchain Proof-of-Work</a>
|
||
<div class="dropdown-divider"></div>
|
||
<a class="dropdown-item disabled"><b>Appendix A</b></a>
|
||
<a class="dropdown-item" href="CLangOverview.html"> A.1. C Language Reintroduction</a>
|
||
<a class="dropdown-item" href="Debugging.html"> A.2. Documentation and Debugging</a>
|
||
<a class="dropdown-item" href="BasicTypes.html"> A.3. Basic Types and Pointers</a>
|
||
<a class="dropdown-item" href="Arrays.html"> A.4. Arrays, Structs, Enums, and Type Definitions</a>
|
||
<a class="dropdown-item" href="Functions.html"> A.5. Functions and Scope</a>
|
||
<a class="dropdown-item" href="Pointers.html"> A.6. Pointers and Dynamic Allocation</a>
|
||
<a class="dropdown-item" href="Strings.html"> A.7. Strings</a>
|
||
<a class="dropdown-item" href="FunctionPointers.html"> A.8. Function Pointers</a>
|
||
<a class="dropdown-item" href="Files.html"> A.9. Files</a>
|
||
</div>
|
||
</li>
|
||
|
||
|
||
|
||
</ul>
|
||
</div>
|
||
|
||
<ul class="navbar-nav flex-row ml-md-auto d-none d-md-flex">
|
||
<li class="nav-item"><a class="nav-link jmu-gold" href="https://w3.cs.jmu.edu/kirkpams/OpenCSF/Books/csf/source/NetApps.rst"
|
||
target="_blank" rel="nofollow">Show Source</a></li>
|
||
|
||
</ul>
|
||
</nav>
|
||
|
||
|
||
<div class="container center">
|
||
«  <a id="prevmod" href="FiveLayer.html">4.2. The TCP/IP Internet Model</a>
|
||
  ::  
|
||
<a class="uplink" href="index.html">Contents</a>
|
||
  ::  
|
||
<a id="nextmod" href="Sockets.html">4.4. The Socket Interface</a>  »
|
||
|
||
</div>
|
||
<br />
|
||
|
||
|
||
|
||
<script type="text/javascript" src="_static/js/jquery-2.1.4.min.js"></script>
|
||
<script type="text/javascript" src="https://cdnjs.cloudflare.com/ajax/libs/mathjax/2.7.1/MathJax.js?config=TeX-AMS-MML_HTMLorMML"></script>
|
||
<script type="text/javascript" src="_static/js/jquery-1.11.4-ui.min.js"></script>
|
||
<script type="text/javascript" src="_static/js/forge-0.7.0.min.js"></script>
|
||
<script type="text/javascript" src="../../../JSAV/lib/jquery.transit.js"></script>
|
||
<script type="text/javascript" src="../../../JSAV/lib/raphael.js"></script>
|
||
<script type="text/javascript" src="../../../JSAV/build/JSAV-min.js"></script>
|
||
<script type="text/javascript" src="_static/js/config.js"></script>
|
||
<script type="text/javascript" src="../../../lib/odsaUtils-min.js"></script>
|
||
<script type="text/javascript" src="../../../lib/odsaMOD-min.js"></script>
|
||
<script type="text/javascript" src="_static/js/d3-4.13.0.min.js"></script>
|
||
<script type="text/javascript" src="_static/js/d3-selection-multi.v1.min.js"></script>
|
||
<script type="text/javascript" src="../../../lib/dataStructures.js"></script>
|
||
|
||
|
||
|
||
|
||
|
||
|
||
<div class="container">
|
||
|
||
<script>ODSA.SETTINGS.DISP_MOD_COMP = true;ODSA.SETTINGS.MODULE_NAME = "NetApps";ODSA.SETTINGS.MODULE_LONG_NAME = "Network Applications and Protocols";ODSA.SETTINGS.MODULE_CHAPTER = "Networked Concurrency"; ODSA.SETTINGS.BUILD_DATE = "2021-06-01 15:31:50"; ODSA.SETTINGS.BUILD_CMAP = false;JSAV_OPTIONS['lang']='en';JSAV_EXERCISE_OPTIONS['code']='java';</script><div class="section" id="network-applications-and-protocols">
|
||
<h1>4.3. Network Applications and Protocols<a class="headerlink" href="NetApps.html#network-applications-and-protocols" title="Permalink to this headline">¶</a></h1>
|
||
<p>While the protocol stack adheres to a layered architecture, network applications typically adhere to
|
||
the <a class="reference internal" href="Glossary.html#term-client-server-architecture"><span class="xref std std-term">client/server</span></a> or <a class="reference internal" href="Glossary.html#term-peer-to-peer-architecture"><span class="xref std std-term">peer-to-peer architectures</span></a>. In both cases, one or more processes on a host creates a <em>server
|
||
socket</em> that listens for incoming connections; at a later time, a process on a different host
|
||
creates a socket to connect to the server socket. In traditional client/server architectures, this
|
||
client process is contacting the server to request access to a resource, such as a web page or a
|
||
user’s email messages; clients are typically untrusted and less privileged than servers, requiring
|
||
some form of authentication to gain access. In a peer-to-peer application, such as file sharing or
|
||
multimedia streaming, both processes are equally privileged and exchange data in both directions;
|
||
however, at some previous point, one of the two processes established a server socket that the other
|
||
connected to.</p>
|
||
<p>In many ways, network applications using the socket interface behave like the message passing IPC
|
||
techniques from the previous chapter. Socket communication can be structured like message queues, or
|
||
they can use byte streams like pipes or FIFOs. In fact, <a class="reference internal" href="Glossary.html#term-unix-domain-socket"><span class="xref std std-term">UNIX domain sockets</span></a> can be used specifically for this local communication. In addition, a Linux <a class="reference internal" href="Glossary.html#term-netlink-socket"><span class="xref std std-term">netlink
|
||
socket</span></a> provides a mechanism to pass messages between the kernel and a user-mode process. However,
|
||
if a process needs to communicate with a process on a different host, however, then sockets are
|
||
required; other forms of IPC do not provide this support.</p>
|
||
<div class="section" id="naming-and-addressing">
|
||
<h2>4.3.1. Naming and Addressing<a class="headerlink" href="NetApps.html#naming-and-addressing" title="Permalink to this headline">¶</a></h2>
|
||
<p>Unlike local IPC, sockets require extra information to set them up. Specifically, when setting up a
|
||
socket to connect to a remote host, a process must provide information about which host and process
|
||
to contact. This information is normally provided to the client process by the user in the form of a
|
||
<a class="reference internal" href="Glossary.html#term-uniform-resource-identifier"><span class="xref std std-term">uniform resource identifier</span></a> (URI). URIs adhere to a common structure:</p>
|
||
<div class="highlight-none border border-dark rounded-lg bg-light px-2 mb-3 notranslate"><div class="highlight bg-light"><pre class="mb-0"><span></span>URI = scheme:[//authority]path[?query][#fragment]
|
||
</pre></div>
|
||
</div>
|
||
<p>The <em>scheme</em> component defines the application-layer protocol that is being used; common
|
||
examples of schemes would be using http or https for web pages, ftp for file transfers, or ssh to
|
||
connect to a remote terminal on another host. The <em>path</em> component consists of a sequence of
|
||
data fields, typically organized to create a hierarchy of resources, joined together by a delimiter.
|
||
For example, the path in a web page URI defines the location of the requested file in that host’s
|
||
file system, relative to the web server’s home directory; if a web server is configured to use the
|
||
directory <code class="docutils literal notranslate"><span class="pre">/etc/apache</span></code> as its home directory, then the path <code class="docutils literal notranslate"><span class="pre">images/icon.gif</span></code> would be used to
|
||
request a copy of the file /etc/apache/images/icon.gif. Note that some applications use a different
|
||
delimiter for a path, such as a colon (<code class="docutils literal notranslate"><span class="pre">':'</span></code>).</p>
|
||
<p>The bracket notation in the URI indicates that the other components are optional, though some
|
||
application protocols may require them. If these components are present, they begin with a
|
||
particular identifying character sequence. The <em>query</em> and <em>fragment</em> components begin
|
||
with the <code class="docutils literal notranslate"><span class="pre">'?'</span></code> and <code class="docutils literal notranslate"><span class="pre">'#'</span></code> characters, respectively, and they can be used to customize the data
|
||
requested. For instance, in a web page that is dynamically constructed by the server, the query
|
||
might be used to provide user input. One example of this would be an e-commerce application that
|
||
uses a URI such as <code class="docutils literal notranslate"><span class="pre">http://mystore.com/itemLookup?itemID=53</span></code> to direct the request to a single
|
||
server-side file (<code class="docutils literal notranslate"><span class="pre">itemLookup</span></code>) that performs a database query for item 53, showing its picture,
|
||
price, and other information.</p>
|
||
<p>The fragment component, on the other hand, is typically used to direct the client application to
|
||
customize the view in some way. For instance, a web browser using the fragment field may jump to a
|
||
section identified in the HTML source with an anchor tag or an ID attribute, rather than displaying
|
||
the default top of the page. The <em>authority</em> component begins with a double slash (<code class="docutils literal notranslate"><span class="pre">'//'</span></code>)
|
||
and adheres to the following structure:</p>
|
||
<div class="highlight-none border border-dark rounded-lg bg-light px-2 mb-3 notranslate"><div class="highlight bg-light"><pre class="mb-0"><span></span>authority = [userinfo@]host[:port]
|
||
</pre></div>
|
||
</div>
|
||
<p>The <code class="docutils literal notranslate"><span class="pre">host</span></code> field is either a domain name or an IP address that is used to locate the host within
|
||
the network. The <code class="docutils literal notranslate"><span class="pre">port</span></code> number is used to identify the process that should receive the application
|
||
data from the packet. Many protocols have a default port number, such as using port 80 for a web
|
||
server communicating via HTTP. Application clients, such as web browsers, fill in this information
|
||
automatically. For instance, entering <code class="docutils literal notranslate"><span class="pre">http://www.foo.com/</span></code> and <code class="docutils literal notranslate"><span class="pre">http://www.foo.com:80/</span></code> would
|
||
yield the same results; both URIs contain the same scheme (<code class="docutils literal notranslate"><span class="pre">http</span></code>), the same host
|
||
(<code class="docutils literal notranslate"><span class="pre">www.foo.com</span></code>), the same path (<code class="docutils literal notranslate"><span class="pre">'/'</span></code>), and the same port (80, implied in the former). The
|
||
<code class="docutils literal notranslate"><span class="pre">userinfo</span></code> field is used if a user identity needs to be associated with the request, as when using
|
||
SSH to log into a user’s account.</p>
|
||
<div class="figure mb-2 align-right" id="id2" style="width: 40%">
|
||
<span id="neturi"></span><a class="reference internal image-reference" href="_images/CSF-Images.4.4.png"><img class="p-3 mb-2 align-center border border-dark rounded-lg" alt="The structure of URIs for three applications" src="_images/CSF-Images.4.4.png" style="width: 90%;" /></a>
|
||
<p class="caption align-center px-3"><span class="caption-text"> Figure 4.3.1: The structure of URIs for three applications</span></p>
|
||
</div>
|
||
<p><a href="NetApps.html#neturi">Figure 4.3.1</a> illustrates the structure of URIs for three example applications. The
|
||
first URI shown illustrates one that may be used to access a page from a web server running on the
|
||
user’s own machine (as indicated by the <code class="docutils literal notranslate"><span class="pre">localhost</span></code> host name in the authority field). Port 8080
|
||
is commonly used as the default port number for local instances of the Apache Tomcat server; so this
|
||
URI may be used to access a Java servlet, providing the username as an input value, then jumping
|
||
down to the section identified by the sec1 HTML ID attribute. The second example shows a URI as it
|
||
may be used in an email application. Note that the URI definition does not impose strict
|
||
requirements on the structure of a path, so an email address is acceptable for that application. The
|
||
last example shows a URI for accessing a newsgroup.</p>
|
||
</div>
|
||
<div class="section" id="protocol-specifications-and-rfcs">
|
||
<h2>4.3.2. Protocol Specifications and RFCs<a class="headerlink" href="NetApps.html#protocol-specifications-and-rfcs" title="Permalink to this headline">¶</a></h2>
|
||
<p>The protocols that govern communication in the Internet are defined and maintained by the
|
||
<a class="reference internal" href="Glossary.html#term-internet-engineering-task-force"><span class="xref std std-term">Internet Engineering Task Force</span></a> (IETF), an international standards organization; IETF is a
|
||
part of a larger non-profit organization, the <a class="reference internal" href="Glossary.html#term-internet-society"><span class="xref std std-term">Internet Society</span></a> (ISOC), that is responsible
|
||
for the leadership and development of the Internet. The aim of IETF is to publish standards to make
|
||
the Internet work better, relying on an open and transparent process with a significant amount of
|
||
volunteer and community effort. The IETF defines these standards in documents known as
|
||
<a class="reference internal" href="Glossary.html#term-request-for-comment"><span class="xref std std-term">requests for comment</span></a> (RFCs). <a class="footnote-reference" href="NetApps.html#f22" id="id1">[1]</a> All RFCs are available for free
|
||
download at <a class="reference external" href="https://tools.ietf.org/rfc/">https://tools.ietf.org/rfc/</a>.</p>
|
||
<p><a class="reference external" href="NetApps.html#tbl4-1">Table 4.1</a> identifies the RFC for several well-known protocols and components of the Internet. To be
|
||
thorough, as shown in the table, there is even a specific RFC that defines the process for creating
|
||
an RFC. Many protocols, such as TCP and IP, have a single core RFC but depend on several others
|
||
beyond the main document. Other protocols spread their core definition over several RFCs; for
|
||
example, the secure shell protocol (SSH) is defined in RFCs 4250 – 4254, with several other RFCs
|
||
defining supporting components. Note that there are many protocols and services, such as the secure
|
||
copy protocol (SCP), that are not defined in any RFC.</p>
|
||
<center>
|
||
<table class="table table-bordered">
|
||
<thead class="jmu-dark-purple-bg text-light">
|
||
<tr>
|
||
<th class="py-0 center">RFC</th>
|
||
<th class="py-0 center">Purpose</th>
|
||
</tr>
|
||
</thead>
|
||
<tbody>
|
||
<tr>
|
||
<td class="py-0 center">768</td>
|
||
<td class="py-0">UDP – unreliable transport layer protocol</td>
|
||
</tr>
|
||
<tr>
|
||
<td class="py-0 center">791</td>
|
||
<td class="py-0">IPv4 – network layer protocol (version 4)</td>
|
||
</tr>
|
||
<tr>
|
||
<td class="py-0 center">793</td>
|
||
<td class="py-0">TCP – reliable transport layer protocol</td>
|
||
</tr>
|
||
<tr>
|
||
<td class="py-0 center">959</td>
|
||
<td class="py-0">FTP – file transfer protocol</td>
|
||
</tr>
|
||
<tr>
|
||
<td class="py-0 center">1034,1035</td>
|
||
<td class="py-0">DNS – domain name translation database</td>
|
||
</tr>
|
||
<tr>
|
||
<td class="py-0 center">2026</td>
|
||
<td class="py-0">Defines the RFC process</td>
|
||
</tr>
|
||
<tr>
|
||
<td class="py-0 center">2131</td>
|
||
<td class="py-0">DHCP – dynamic IP addressing</td>
|
||
</tr>
|
||
<tr>
|
||
<td class="py-0 center">2616</td>
|
||
<td class="py-0">HTTP/1.1 – serving web page</td>
|
||
</tr>
|
||
<tr>
|
||
<td class="py-0 center">3986</td>
|
||
<td class="py-0">Structure and interpretation of a URI</td>
|
||
</tr>
|
||
<tr>
|
||
<td class="py-0 center">8200</td>
|
||
<td class="py-0">IPv6 – network layer protocol (version 6)</td>
|
||
</tr>
|
||
</tbody>
|
||
</table>
|
||
<p>
|
||
Table 4.1: RFCs for some well-known Internet services
|
||
</p>
|
||
</center><p>RFCs for protocols typically include multiple sections, such as definitions of key terms,
|
||
illustrations of the structure and timing of messages, explanations status and error messages, and
|
||
security analyses. Some RFCs are very short, as short as a few pages in PDF format; others can be
|
||
more than 100 pages. One key feature that is common is the use of :<em>ackus-Naur Form (BNF)</em>, a
|
||
formal method for defining information about a language or a set of messages. Reading BNF is a key
|
||
skill for understanding the protocol specifications in RFCs. As an example, consider the following
|
||
portion of the HTTP/1.1 specification in RFC 2616:</p>
|
||
<div class="highlight-none border border-dark rounded-lg bg-light px-2 mb-3 notranslate"><div class="highlight bg-light"><pre class="mb-0"><span></span>HTTP-message = Request | Response
|
||
Request = Request-line
|
||
*(( general-header
|
||
| request-header
|
||
| entity-header ) CRLF)
|
||
CRLF
|
||
[ message-body ]
|
||
Request-Line = Method SP Request-URI SP HTTP-Version CRLF
|
||
</pre></div>
|
||
</div>
|
||
<p>These lines illustrate several key features of BNF. The text to the left of an equal sign (<code class="docutils literal notranslate"><span class="pre">'='</span></code>)
|
||
declare a unique type of <em>entity</em> that serves as a basic language feature; in this case, these
|
||
lines define the structure of the entities <code class="docutils literal notranslate"><span class="pre">HTTP-message</span></code>, <code class="docutils literal notranslate"><span class="pre">Request</span></code>, and <code class="docutils literal notranslate"><span class="pre">Request-Line</span></code>. The
|
||
vertical bar (<code class="docutils literal notranslate"><span class="pre">'|'</span></code>) denotes a choice operation that can be satisfied by either entity; for
|
||
instance, an <code class="docutils literal notranslate"><span class="pre">HTTP-message</span></code> can be either a <code class="docutils literal notranslate"><span class="pre">Request</span></code> or a <code class="docutils literal notranslate"><span class="pre">Response</span></code>. Consecutive lines
|
||
indicate multiple entities that are required in a particular sequence; the line breaks in BNF do not
|
||
have a specific meaning and only serve the purpose of making the definition more readable. The
|
||
parentheses are used for grouping entities, the <em>Kleene star</em> character (<code class="docutils literal notranslate"><span class="pre">'*'</span></code>) indicates
|
||
that an entity may appear zero or more times, and the brackets indicate an optional entity that may
|
||
appear once or may be omitted. The <code class="docutils literal notranslate"><span class="pre">CRLF</span></code> entity denotes the character sequence “carriage
|
||
return-line feed” that consists of ASCII character 13 (<code class="docutils literal notranslate"><span class="pre">'\r'</span></code>) followed by ASCII character 10
|
||
(<code class="docutils literal notranslate"><span class="pre">'\n'</span></code>), and the <code class="docutils literal notranslate"><span class="pre">SP</span></code> entity denotes a single space (ASCII code 32, <code class="docutils literal notranslate"><span class="pre">'</span> <span class="pre">'</span></code>).</p>
|
||
<div class="topic border border-dark rounded-lg bg-light px-2 mb-3" id="netappsex">
|
||
<div class="figure align-left">
|
||
<a class="reference internal image-reference" href="_images/CSF-Images-Example.png"><img alt="Decorative example icon" src="_images/CSF-Images-Example.png" style="width: 100%;" /></a>
|
||
</div>
|
||
<p class="topic-title first pt-2 mb-1">Example 4.3.1 </p><hr class="mt-1" />
|
||
<p>To combine these BNF rules in an example, an HTTP Request must begin with exactly one
|
||
<code class="docutils literal notranslate"><span class="pre">Request-line</span></code> followed by some sequence of entities (possibly an empty sequence) that must be
|
||
either a <code class="docutils literal notranslate"><span class="pre">general-header</span></code>, <code class="docutils literal notranslate"><span class="pre">request-header</span></code>, or <code class="docutils literal notranslate"><span class="pre">entity-header</span></code>; there can be multiple
|
||
instances of each of these headers and they can appear in any order. After all of the headers,
|
||
there must be a single blank line ending in <code class="docutils literal notranslate"><span class="pre">CRLF</span></code>, followed by an optional message body. The
|
||
<code class="docutils literal notranslate"><span class="pre">Request-line</span></code> that starts the <code class="docutils literal notranslate"><span class="pre">Request</span></code> must consist of a <code class="docutils literal notranslate"><span class="pre">Method</span></code> (such as <code class="docutils literal notranslate"><span class="pre">GET</span></code> or
|
||
<code class="docutils literal notranslate"><span class="pre">POST</span></code>), a <code class="docutils literal notranslate"><span class="pre">Request-URI</span></code> (which is different but related to the general URI previously
|
||
discussed), and an <code class="docutils literal notranslate"><span class="pre">HTTP-Version</span></code>, separated by spaces and ending with a <code class="docutils literal notranslate"><span class="pre">CRLF</span></code>. As an example,
|
||
the following lines of code is a valid <code class="docutils literal notranslate"><span class="pre">HTTP-message</span></code>:</p>
|
||
<div class="highlight-none border border-dark rounded-lg bg-light px-2 mb-3 notranslate"><div class="highlight bg-light"><pre class="mb-0"><span></span>GET index.html HTTP/1.0
|
||
Accept-Charset: iso-8859-5, Unicode-1-1
|
||
Date: Tue, 19 Nov 2018 08:12:31 GMT
|
||
Accept-Encoding: *
|
||
</pre></div>
|
||
</div>
|
||
<p>This example illustrates a <code class="docutils literal notranslate"><span class="pre">GET</span></code> request using HTTP version 1.0 to request a copy of the file
|
||
designated by the <code class="docutils literal notranslate"><span class="pre">Request-URI</span></code> <code class="docutils literal notranslate"><span class="pre">index.html</span></code>. The <code class="docutils literal notranslate"><span class="pre">Accept-Charset</span></code> and <code class="docutils literal notranslate"><span class="pre">Accept-Encoding</span></code>
|
||
lines are examples of the <code class="docutils literal notranslate"><span class="pre">request-header</span></code> entity types, while the <code class="docutils literal notranslate"><span class="pre">Date</span></code> is a
|
||
<code class="docutils literal notranslate"><span class="pre">general-header</span></code>. Each line ends with a <code class="docutils literal notranslate"><span class="pre">CRLF</span></code>, including the last line, which has no other
|
||
text.</p>
|
||
</div>
|
||
<table class="docutils footnote" frame="void" id="f22" rules="none">
|
||
<colgroup><col class="label" /><col /></colgroup>
|
||
<tbody valign="top">
|
||
<tr><td class="label"><a class="fn-backref" href="NetApps.html#id1">[1]</a></td><td>The term <a class="reference internal" href="Glossary.html#term-request-for-comment"><span class="xref std std-term">request for comment</span></a> may seem to suggest that the document is an early draft
|
||
that will be revised later after feedback from the community. This is, to an extent, actually true.
|
||
The protocols themselves are frequently revised or extended, so many RFCs <em>obsolete</em> others as the
|
||
structure and functioning of the Internet evolves. Consequently, the name <a class="reference internal" href="Glossary.html#term-rfc"><span class="xref std std-term">RFC</span></a> is appropriate
|
||
because they serve as requests for the public to consider the current status of the Internet,
|
||
proposing improvements where needed.</td></tr>
|
||
</tbody>
|
||
</table>
|
||
<div
|
||
id="AppsSumm"
|
||
class="embedContainer"
|
||
data-exer-name="AppsSumm"
|
||
data-long-name="Socket application questions"
|
||
data-short-name="AppsSumm"
|
||
data-frame-src="../../../Exercises/Sockets/AppsSumm.html?selfLoggingEnabled=false&localMode=true&module=NetApps&JXOP-debug=true&JOP-lang=en&JXOP-code=java"
|
||
data-frame-width="950"
|
||
data-frame-height="550"
|
||
data-external="false"
|
||
data-points="1.0"
|
||
data-required="True"
|
||
data-showhide="show"
|
||
data-threshold="5"
|
||
data-type="ka"
|
||
data-exer-id="">
|
||
|
||
<div class="center">
|
||
<div id="AppsSumm_iframe"></div>
|
||
</div>
|
||
</div>
|
||
</div>
|
||
</div>
|
||
|
||
|
||
</div>
|
||
|
||
|
||
|
||
<div class="container">
|
||
|
||
<div class="mt-4 container center">
|
||
«  <a id="prevmod1" href="FiveLayer.html">4.2. The TCP/IP Internet Model</a>
|
||
  ::  
|
||
<a class="uplink" href="index.html">Contents</a>
|
||
  ::  
|
||
<a id="nextmod1" href="Sockets.html">4.4. The Socket Interface</a>  »
|
||
</div>
|
||
|
||
|
||
</div>
|
||
|
||
<br />
|
||
|
||
<div class="row jmu-dark-purple-bg">
|
||
<div class="col-md-12">
|
||
<center>
|
||
<a id="contact_us" class="btn button-link-no-blue jmu-gold" rel="nofollow" href="mailto:webmaster@opencsf.org" role="button">Contact Us</a>
|
||
<a id="license" class="btn button-link-no-blue jmu-gold" rel="nofollow" href="https://w3.cs.jmu.edu/kirkpams/OpenCSF/lib/license.html" target="_blank">License</a>
|
||
</center>
|
||
</div>
|
||
</div>
|
||
|
||
|
||
|
||
|
||
|
||
|
||
<script src="_static/js/popper.js-1.14.7-min.js" integrity="sha384-UO2eT0CpHqdSJQ6hJty5KVphtPhzWj9WO1clHTMGa3JDZwrnQq4sF86dIHNDz0W1" crossorigin="anonymous"></script>
|
||
<script src="_static/js/bootstrap.min.js" integrity="sha384-JjSmVgyd0p3pXB1rRibZUAYoIIy6OrQ6VrjIEaFf/nJGzIxFDsf4x0xIM+B07jRM" crossorigin="anonymous"></script>
|
||
</body>
|
||
</html> |