001
`
`

`
`~
`'\"111!
`
`The Morgan Kaufmann Series in Networking
`Series Editor, David Clark, M.I.T.
`
`Computer Networks: A Systems Approach, 3e
`Larry L. Peterson and Bruce S. Davie
`Network Architecture, Analysis, and Design, 2e
`Jam~s D. McCabe
`MPLS Network Management: MIBs, Tools, and Techniques
`Thomas D. Nadeau
`Developing IP-Based Services: Solutions for Service Providers ,md Vendors
`Monique Morrow and Kateel Vijayananda
`Telecommunications Law in the Internet Age
`Sharon K. Black
`Optical Networks: A Practical Perspecth,e; 2e
`Ra)iv Ramaswami and Kumar N. Sivarajan
`Internet QoS:. Architectures and Mechanisms
`Zheng Wang
`TCPIIP Sockets' in java: Practical Guide for Programmers
`Michael J. Donahoo and Kenneth L. Calvert
`TCP!IP Sockets inC: Practical Guide for Programmers
`Kenneth L. Calvert and Michael J. Donahoo
`Multicast (_:ommunication: Protocols, Programming, and Applic<~tions
`Ralph Wittmann and Martina Zitterbart
`MPLS: Te.clmo/ogy and Applications
`Bruce Davie and Yakov Rekhter
`High··Performcmce Communication Networks, 2e
`Jean Walrand and Pravin Varaiya
`Internetworking Multimedia
`Jon Crowcroft, Mark Hatidley, and Ian Wakeman
`Underst;nding Networked AfJp!imtidns: A First Course
`David G. Messerschmitt
`Integrated Management of Networked Systems: Concepts, Architectures,
`and their Operational Application
`· Heinz-Gerd Hegering, Sebastian A beck, and Bernhard Neumair
`\iirtual Private Networks: Making the Right Connection
`Dennis fowler
`Networked Applications: A Guide to the New Compllting ln(rastructure
`David G. Messerschmitt
`Modern Cahl.e Teleuision Technology: \/ideo, V01ce, and Data Commzmications
`Walter Ciciora, James Farmer, and David Large
`Switching in IP Networks: IP Switching, Tag Switching, and Related Technologies
`Bruce S. Davie, Paul Dool;n, and Yakov Rckhter
`Wide Area Networ" Design: Concepts ,md Tools for Optimization
`Robert S. Calm
`Frame Relay AptJlicaticms: Business and Techlzo/r)gy Czse Studies
`James P. Cavanagh
`
`For further information on these books and for a list of forthcoming titles, please visit
`our website at http://www.mkp.com '
`
`002
`
`

`
`THIRD EIDTION
`
`Larry L. Peterson & Bruce S. Davie
`
`COMPUTER
`NETWORKS
`
`A Systems Approach
`
`Morgan Kaufmann Publishers
`An Imprint of Elsevier
`
`...
`
`003
`
`

`
`Computer Networks: A Systems Approach
`Peterson & Davie
`
`MORGAN KAUFMANN PUBLISHERS
`An Imprint of Elsevier
`340 Pine Street, Sixth Floor
`San Francisco, CA 94104-3205, USA
`
`© 2003 by Elsevier
`
`Original ISBN : 0-55860-833-8
`
`All rights reserved.
`
`No part of this publication may be reproduced or transmitted in any form or
`by any means-electronic or mechanical, including photocopy, recording, or
`any information storage and retrieval system-without permission in writing
`from the publisher.
`
`First Printed in India 2003
`Reprinted 2004
`Reprinted 2005
`Reprinted 2006
`Indian Reprint ISBN-13: 978-81-8147-206-9
`Indian Reprint ISBN-10: 81-8147-206-3
`
`This edition is for sale in Bangladesh, Bhutan, India, Maldives, Napa!, Pakistan,
`Sri Lanka and designated countries in South-East Asia through Elsevier (Singapore)
`Pte Ltd. Sale and purchase of this book outside of these countries is unauthorised
`by the publisher.
`
`Published by Elsevier, a division of Reed Elsevier India Private Limited,
`Shri Pratap Udyog, 274, Captain Gaur Marg, Sriniwaspuri,
`New Delhi-11 0065 (India).
`
`Printed and bound at Saurabh Printers Pvt. Ltd.,
`A-16, Sector IV, NOIDA-201 301.
`
`004
`
`

`
`1.4 Implementing Network Software
`
`31
`
`implementing the protocols running within the network. In many respects, network
`applications and network protocols are very similar-the way an application e~gages
`the services of the network is pretty mu.ch the same as the way a high-level protocol
`invokes the services of a low-level protocol. As we will see later in the section, however,
`there are a couple of important differences:
`
`1.4. 1 Application Programming Interface (Sockets)
`The place to start when implementing a network application is the interface exported
`by the network. Since most network protocols are implemented in software (espe(cid:173)
`cially .those high in the protocol stack), and nearly ail computer systems implement .
`their network protocols as part of the operating system, wh~n we refer to the inter(cid:173)
`face "exported by the network," we are generally referring to the interface that the
`OS provides to its networking subsystem. This interface is often called the network
`application programming interface (API).
`.
`Although each operating system is free to define its own network API (and most
`have), over time certain of these APis have become widely supported; tliat is, they
`have been ported to operating systems other than their native system. This is what has
`happened with the socket interface originally provided by the Berkeley distribution of
`Unix, which is now supported in virtually all popular operating systems. The advantage
`of industrywide support for a single API is that applications can· be easily ported from
`one OS to another. It is important to keep in mind, however, that application programs
`typically interact with many parts of the OS other than the network; for example, they
`read and write files, fork concurrent processes, and output to the graphical display.
`Just because two systems support the same network API does not mean that their
`file syste.m, process, or graphic interfaces are the same. ·Still, understanding a widely
`adopted API like Unix sockets gives us a good place to start.
`Before describing the socket interface, it is important to keep two concerns sep(cid:173)
`arate in your mind. Each prot~lCol provides a certain set of services, and the API
`provides a syntax by which those services can be invo~ed in this particular OS.
`The implementation is then responsible for mapping the tangible set of operations ·
`and objects defined by the API onto the abstract set of services defined by the pro(cid:173)
`tocol. If you have done a good job of defining the interface, then it will be possible
`to use the syntax of the interface to invoke the services of many different protocols.
`Such generality was certainly a goal of the socket interface, altnough it's far from
`perfect.
`The main abstraction of the socket interface, not surprisingly, is the socket. A
`good way to think of a socket is as the point where a• local application process attaches
`to the network. The interface defines operations for creating a socket, attaching the
`sqcket to the network, sending/receiving messages through the socket, and closing the
`
`005
`
`

`
`32
`
`1 Foundation
`
`socket. To sirl)plify the discussion, we will limit ourselves to showing how sockets are
`used with TCP.
`The first step is to create a socket, which is done with the following operation:
`
`int socket(int domain, int type, int protocol)
`
`The reason that this operation takes three arguments is that the socket interface was
`designed to be general enough to support any underlying protocol suite. Specifically, the
`domain argument specifies the protocol family that is going to be used: PF _!NET denotes
`the Internet family, PF _UNIX denotes the Unix pipe facility, and PF _PACKET denotes
`direct access to the network interface (i.e., it bypasses the TCP/IP protocol stack). The
`type argument indicates the semaptics of the communication. SOCK_STREAM is used to
`denote a byte stream. SOCK_DGRAM is an alternative that denotes a message-oriented
`service, such as that provided by UDP. The protocol argument identifies the specific
`protocol that is going to be used. In our case, this argument is UNSPEC because the
`combination of PF JNET and SOCK_STREAM implies TCP. Finally, the return value from
`socket is a handle for the newly created socket, that is, an identifier by which we can
`refer to the socket in the future. It is given as an argument to subsequent operations
`on this socket.
`Th:e next step depends on whether you are a client or a server. On a server
`machine, the application process performs a passive open_:the server says that it is
`prepared to accept connections, but it does not actually establish a connection. The
`server does this by invoking the following three operations:
`
`int bind(int socket, struct sockaddr *address, int addrJen)
`int listen(int socket, int backlog)
`int accept(int socket, struct sockaddr *address, int *addr Jen)
`
`The bind operation, as its name suggests, binds the newly created socket to the
`specified address. This is the network address of the local participant-the server. Note
`that, when used with the Internet protocols, address is a data structure that includes
`both the IP address of the server and a TCP port number. (As we will see in Chapter 5,
`ports arP used to indirectly identify processes. They are a form of demux keys as de(cid:173)
`fined in Section 1.3.1.) The port number is usually some well-known number specific
`to the service being offered; for example, Web servers commonly accept connections
`on port 80.
`The listen operation then defines how many connections can be pending on
`the specified socket. Finally; the accept operation carries out the passive open. It is
`a blocking operation that does not return until a remote participant has established
`a connection, and when it does complete, it returns a new socket that corresponds
`to this just-established connection, and the address, argument contains the remote
`
`006
`
`

`
`36
`
`1 Foundation
`
`!* setup passive open */
`if ((s
`socket(PF~INET, SOCK_STREAM, 0)) < 0)
`perror("simplex-talk: socket");
`exit(l);
`
`{
`
`if ((bind(s, (struct sockaddr *)&sin, sizeof(sin))) < 0)
`perror ("simplex-talk: bind") ;
`exit(l);
`
`{
`
`listen (s, MAX_PENDING);
`
`/* wait for connection, then receive and print text */
`while (1)
`{
`if ( (new_s.= accept(s, (struct sockaddr *)&sin, &len)) < 0) {
`perror("simplex-talk: accept");
`ex:Lt ( 1);
`}
`while (len= recv(new_s, buf, sizeof(buf), 0))
`fputs (buf ,_ stdout) ;
`close(new_s);
`
`1.4.3 Protocol Implementation Issues
`As mentioned at the beginning .of this section, the way application programs interact
`with the underlying network is similar to the way a high-level protocol interacts with
`a low-level protocol. For example, TCP needs an interface to send outgoing messages
`to IP, and IP needs to be able to deliver incoming messages to TCP. This is exactly the
`service interface introduced in Section 1.3 .1.
`Since we already have a network API (e.g., sockets), we might be tempted to use
`this same interface between every pair of protocols in the protocol stack. Although
`certainly an option, in practice the socket interface is not used in this way. The reason
`is that there are inefficiencies built into the socket interface that protocol implementers
`are not willing to tolerate. Application programmers tolerate them because they sim(cid:173)
`plify their programming task and because the inefficiency only has to be tolerated once,
`but protocol implementers are often obsessed with performance and must worry about
`getting a message through several layers of protocols. The rest of this section discusses
`the two primary differences between the network API and the protocol-to-protocol
`interface found lower in the protocol graph.
`
`Process Model
`Most operating systems provide an abstraction called a process, or alternatively,. a
`thread. Each process runs. largely independently of other processes, and the OS is
`
`007
`
`

`
`1.4 Implementing Network Software
`
`37
`
`j
`
`~
`R n
`~ n
`0
`ES
`~
`
`(a)
`
`(b)
`
`Figure 1.16 Alternative process models: (a) process-per-protocol; (b) process-per·
`message.
`
`responsible for making sure that resources, such as address space and CPU cycles,
`are allocated to all the current processes. The process abstraction makes it fairly
`straightforward to have a lot of things executing concurrently on one machine; for
`example, each user application might execute in its own process, and various things
`inside the OS might execute as other processes. When the OS stops one process from
`executing on the CPU and starts up another one, we call the change a context switch.
`When designing the network subsystem, one of the first questions to answer
`is, "Where are the processes?" There are essentially two choices, as illustrated in
`Figure 1.16. In the first, which we call the process-per-pro'tocol model, each protocol
`is implemented by a separate process. This means that as a message moves up or down
`the protocol stack, it is passed from one process/protocol to another-the process that
`implements protocol i processes the message, then passes it to protocol i - 1, and so
`on. How one process/protocol passes a message to the next process/protocol depends
`on the support the host OS provides for interprocess communication. Typically, there
`is a simple mechanism for enqueuing a message with a process. The important point)
`however, is that a context switch is required at each level of the protocol graph(cid:173)
`typically a time-consuming operation.
`The alternative, which we call the process-per-message model, treats each pro(cid:173)
`tocol as a static piece of code and associates the processes with the messages.
`
`008
`
`

`
`009