FOURTH EDITION I
`
`~omputer Networks
`
`ANDREW S. TANENBAUM
`
`Page 1 of 27
`
`GOOGLE EXHIBIT 1006
`
`

`

`Computer Networks
`Fourth Edition
`
`ISBN □ -13-0661□2-3
`
`Page 2 of 27
`
`

`

`Other bestselling titles by Andrew S. Tanenbaum
`
`Distributed Systems: Principles and Paradigms
`This new book, co-authored with Maarten van Steen, covers both the principles
`and paradigm of modem distributed sy terns. In the first part, it covers the prin(cid:173)
`c:iple: of communication, processes, naming, synchronization consi tency and
`replication fault tolerance. and security in detail. Then in the se<.:uutl part it goes
`into different paradigm u ed to build distributed systems, including object-based
`systems, distributed file sy:sltw5, document based systems, anti r.oordination(cid:173)
`ba ed systems. Numerous examples are discussed at length.
`
`Modern Operating Systems, 2nd edition
`This comprehensive text cover
`the principles of modern operating systems i.n
`detail and illu trates them with numerous real-world examples. After an introduc(cid:173)
`tory chapter, the next five chapter deal with the basic concepts: processes and
`threads, deadlocks, memory management, input/output, and file systems. The
`next six chapters deal with more advanced material, including multimedia sys(cid:173)
`tems, multiple processor systems, security. Finally, two detailed case studies are
`given: UNIX/Linux and Windows 2000.
`
`Structured Computer Organization, 4th edition
`This widely-n~;id classic, now in it fourth edition, provides the ideal introduction
`to computer architecture. It covers the topic i11 an easy-to-under tand way, boL(cid:173)
`tom up. There is a chapter on digital logic for beginners followed by chapters on
`microarchitecture, the instruction set architecture level, operating systems, assem(cid:173)
`bly language, and parallel computer architectures.
`
`Operating Systems: Design and Implementation, 2nd edition
`This popular text on operating sy terns, co-authored with Albert S. Woodhull i
`the only book covering both the pdnciples of operating systems and their applica(cid:173)
`tion to a real ystem. All the traditional operating . ystems topics are covered in
`detail. In addition, the principles are carefully illu traced with MINIX, a free
`POSIX-based UNIX-like operating system for per onal computer . Each book
`contains a free CD-ROM containing the complete MINIX system, including all
`the source code. The source code is listed in an appendix to the book and
`explained in detail in the text.
`
`Page 3 of 27
`
`

`

`Computer Networks
`Fourth Edition
`
`Andrew S. Tanenbaum
`Vrije Universiteit
`Amsterdam, The Netherlands
`
`■ Prentice Hall PTR
`
`Upper Saddle River, NJ 07458
`www.phptr.com
`
`Page 4 of 27
`
`

`

`Library of Congress Cataloging-in-Publication Data
`
`Tanenbaum, Andrew S.
`Computer networks / Andrew S. Tanenbaum.--4th ed.
`p. cm.
`Includes bibliographical references.
`ISBN 0-13-066102-3
`I. Computer networks. I. Title.
`TK5105.5 .T36 2002
`004.6--dc2 l
`
`2002029263
`
`Editorial/production supervision: .Parti G11Prrif'ri
`Cover design director: Jerry Votta
`Cover designer: Anthony Gemme/Laro
`Cover design: Andrew S. Tanenbaum
`Art director: Gail Cocker-Bogusz
`Interior Design: Andrew S. Tanenbaum
`Interior graphics: Hadel Studio
`Typesetting: Andrew S. Tan enbaum
`Manufacturing buyer: Maura Zaldivar
`Executive editor: Mary Franz
`Editorial assistant: Noreen Regina
`Marketing manager: Dan DePasquale
`
`■ © 2003, 1996 Pearson Education, Inc.
`Publishing as Prentice Hall PTR
`Upper Saddle River, New Jersey 07458
`
`Prentice Hall books are widely used by corporations and government agencies for training,
`marketing, and resale.
`
`For information regarding corporate and government bulk discounts please contact:
`Corporate and Government Sales (800) 382-3419 or corpsales@pearsontechgroup.com
`
`All products or services mentioned in this book are the trademarks or service marks of their
`respective companies or organizations.
`
`All rights reserved. No part of this book may be reproduced, in any form or by any means,
`without permission in writing from the publisher.
`
`Printed in the United States of America
`
`10 9 8 7 6 5 4 3
`
`ISBN 0-13-066102-3
`
`Pearson Education LTD.
`Pearson Education Australia PTY, Limited
`Pearson Education Singapore, Pte. Ltd.
`Pearson Education North Asia Ltd.
`Pearson Education Canada, Ltd.
`Pearson Educaci6n de Mexico, S.A. de C.V.
`Pearson EdL1cation -
`Japan
`Pearson Education Malaysia, Pte. Ltd.
`
`Page 5 of 27
`
`

`

`524
`
`THE TRANSPORT LA YER
`
`CHAP. 6
`
`connection record, are listed. If an action involves waking up a sleeping process,
`the actions following the wakeup also count. For example, if a CALL REQUEST
`packet comes in and a process was asleep waiting for it, the transmission of the
`CALL ACCEPT packet following the wakeup counts as part of the action for CALL
`REQUEST. After each action is performed, the connection may move to a new
`state, as shown in Fig. 6-21.
`The advantage of representing the protocol as a matrix is threefold. First, in
`this form it is much easier fur Lhe programmer Lo systematically check each com(cid:173)
`bination of state and event to see if an action is required. In production imple(cid:173)
`mentations, some of the combinations would be used for error handling. In
`Fig. 6-21 no distinction is made between impossible situations and illegal ones.
`For example, if a connection is in waiting state, the DISCONNECT event is impossi(cid:173)
`ble because the user is blocked and cannot execute any primitives at all. On the
`other hand, in sending state, data packets are not expected because no credit has
`been issued. The arrival of a data packet is a protocol error.
`The second advantage of the matrix representation of the protocol is in imple(cid:173)
`menting it. One could envision a two-dimensional array in which element a [i] U]
`was a pointer or index to the procedure that handled the occurrence qf event i
`when in state j. One possible implementation is to write the transport entity as a
`short loop, waiting for an event at the top of the loop. When an event happens,
`the relevant connection is located and its state is extracted. With the event and
`state now known, the transport entity just indexes into the array a and calls the
`proper procedure. This approach gives a much, more regular and systematic de(cid:173)
`sign than our transport entity.
`The third advantage of the finite state machine approach is for protocol
`description. In some standards documents, the protocols are given as finite state
`machines of the type of Fig. 6-21. Going from this kind of description to a work(cid:173)
`ing transport entity is much easier if the transport entity is also driven by a finite
`state machine based on the one in the standard.
`The primary disadvantage of the finite state machine approach is that it may
`be more difficult to understand than the straight programming example we used
`initially. However, this problem may be partially solved by drawing the finite
`state machine as a graph, as is done in Fig. 6-22.
`
`6.4 THE INTERNET TRANSPORT PROTOCOLS: UDP
`
`The Internet has two main protocols in the transport layer, a connectionless
`protocol and a connection-oriented one. In the following sections we will study
`both of them. The connectionless protocol is UDP. The connection-oriented pro(cid:173)
`tocol is TCP. Because UDP is basically just IP with a short header added, we will
`start with it. We will also look at two applications of UDP.
`
`,,
`
`Page 6 of 27
`
`

`

`SEC. 6.4
`
`THE INTERNET TRANSPORT PROTOCOLS: UDP
`
`525
`
`CONNECT
`
`/
`
`(
`
`IDLE
`
`TIMEOUT
`
`'
`
`'
`
`( CLEAR REQ
`
`CAL~ REQ)
`
`WAITING
`
`l CALLACC
`
`CREDIT,
`
`( CLEAR REQ
`
`SENDING
`
`SEND
`
`.a I-
`0
`z w w
`w a: z
`z
`I-
`....J
`en
`....J
`0
`::J <t
`0 en
`(.)
`0
`
`ESTAB-
`LISHED
`
`QUEUED
`
`j
`
`LISTEN
`
`RECEIVE
`
`j~ l DATA,
`
`CLEAR REQ
`
`z
`0
`0 en
`0
`
`)
`
`RECEIVING
`
`DISCON-
`NECTING
`
`l
`
`CLEAR REQ, CLEAR CONF
`
`Figure 6-22. The example protocol in graphical form . Transitions that leave
`the connection state unchanged have been omitted for simplicity.
`
`6.4.1 Introduction to UDP
`
`The Internet protocol suite supports a connectionless transport protocol, UDP
`(User Datagram Protocol). UDP provides a way for applications to send encap(cid:173)
`sulated IP datagrams and send them without having to establish a connection.
`UDP is described in RFC 768.
`UDP transmits segments consisting of an 8-byte header followed by the pay(cid:173)
`load. The header is shown in Fig. 6-23. The two ports erve to identify the end
`points within the source and destination machines. When a UDP packet arrives,
`its payload is handed to the process attached to the destination port. This attach(cid:173)
`ment occurs when BIND primitive or something similar is used, as we saw in
`Fig. 6-6 for TCP (the binding process is the same for UDP). In fact, the main
`value of having UDP over just using raw IP is the addition of the source and desti(cid:173)
`nation ports. Without the port fields, the transport layer would not know what to
`do with the packet. With them, it delivers segments correctly.
`
`Page 7 of 27
`
`

`

`526
`
`THE TRANSPORT LAYER
`
`CHAP. 6
`
`- - - - -- -- - -----32 Bits--- -- - -- -- -- - -
`' I I
`
`Source port
`
`UDP length
`
`Destination port
`
`UDP checksum
`
`Figure 6-23. The UDP header.
`
`The source port is primarily needed when a reply must be sent back to the
`source. By copying the source port field from the incoming segment into the des(cid:173)
`tination port field of the outgoing segment, the process sending the reply can
`specify which process on the sending machine is to get it.
`The UDP length field includes the 8-byte header and the data. The UDP
`checksum is optional and stored as O if not computed (a true computed O is stored
`as all ls). Turning it off is foolish unless the quality of the data does not matter
`(e.g., digitized speech).
`It is probably worth mentioning explicitly some of the things that UDP does
`not do. It does not do flow control, error control, or retransmission upon receipt
`of a bad segment. All of that is up to the user processes. What it does do is pro(cid:173)
`vide an interface to the IP protocol with the added feature of demultiplexing mul(cid:173)
`tiple processes. using the ports. That is all it does. For applications that need to
`have precise control over the packet flow, error control, or timing, UDP provides
`just what the doctor ordered.
`One area where UDP is especially useful is in client-server situations. Often,
`the client sends a short request to the server and expects a short reply back. If
`·either the request or reply is lost, the client can just time out and try again. Not
`only is the code simple, but fewer messages are required ( one in each direction)
`than with a protocol requiring an initial setup.
`An application that uses UDP this way is DNS (the Domain Name System),
`which we will study in Chap. 7. In brief, a program that needs to look up the IP
`address of some host name, for example, www.cs.berkeley.edu, can send a UDP
`packet containing the host name to a DNS server. The server replies with a UDP
`packet containing the host's IP address. No setup is needed in advance and no
`release is needed afterward. Just two messages go over the network.
`
`6.4.2 Remote Procedure Call
`
`In a certain sense, sending a message to a remote host and getting a reply back
`is a lot like making a function call in a programming language. In both cases you
`start with one or more parameters and you get back a result. This observation has
`led people to try to arrange request-reply interactions on networks to be cast in the
`
`Page 8 of 27
`
`

`

`SEC. 6.4
`
`THE INTERNET TRANSPORT PROTOCOLS: UDP
`
`527
`
`form of procedure calls. Such an an·angement makes network applications much
`easier to program and more familiar to deal with. For example, just imagine a
`procedure named getJP _address (host.Jlame) that works by sending a UDP pac(cid:173)
`ket to a DNS server and waiting for the reply, timing out and trying again if one is
`not forthcoming quickly enough. In this way, all the details of networking can be
`hidden from the programmer.
`The key work in this area was done by Birrell and Nelson (1984). In a nut(cid:173)
`shell, what Birrell and Nelson suggested was allowing programs to call pro(cid:173)
`cedures located on remote hosts. When a process on machine 1 calls a procedure
`on machine 2, the calling process on 1 is suspended and execution of the called
`procedure takes place on 2. Information can be transported from the caller to the
`callee in the parameters and can come back in the procedure result. No message
`passing is visible to the programmer. This technique is known as RPC (Remote
`Procedure Call) and has become the basis for many networking applications.
`Traditionally, the calling procedure is known as the client and the called pro(cid:173)
`cedure is known as the server, and we will use those names here too.
`The idea behind RPC is to make a remote procedure call look as much as pos(cid:173)
`sible like a local one. In the simplest form, to call a remote procedure, the client
`program must be bound with a small library procedure, called the client stub, that
`represents the server procedure in the client's address space. Similarly, the server
`is bound with a procedure called the server stub. These procedures hide the fact
`that the procedure call from the client to the server is not local.
`The actual steps in making an RPC are shown in Fig. 6-24. Step 1 is the
`client calling the client stub. This call is a local procedure call, with the parame(cid:173)
`ters pushed onto the stack in the normal way. Step 2 is the client stub packing the
`parameters into a message and making a system call to send the message. Pack(cid:173)
`ing the parameters is called marshaling. Step 3 is the kernel sending the message
`from the client machine to the server machine. Step 4 is the kernel passing the
`incoming packet to the server stub. Finally, step 5 is the server stub calling the
`server procedure with the unmarshaled parameters. The reply traces the same
`path in the other direction.
`The key item to note here is that the client procedure, written by the user, just
`makes a normal (i.e., local) procedure call to the client stub, which has the same
`name as the server procedure. Since the client procedure and client stub are in the
`same address space, the parameters are passed in the usual way. Similarly, the
`server procedure is called by a procedure in its address space with the parameters
`it expects. To the server procedure, nothing is unusual. In this way, instead of
`I/O being done on sockets, network communication is done by faking a normal
`procedure call.
`Despite the conceptual elegance of RPC, there are a few snakes hiding under
`the grass. A big one is the use of pointer parameters. Normally, passing a pointer
`to a procedure is not a problem. The called procedure can use the pointer in the
`same way the caller can because both procedures live in the same virtual address
`
`Page 9 of 27
`
`

`

`528
`
`THE TRANSPORT LAYER
`
`CHAP. 6
`
`Client CPU
`
`Server CPU
`
`Client
`stub
`
`Server
`stub
`
`Operating system
`
`3
`
`' Network
`
`Figure 6-24. Steps in making a remote procedure call. The stubs are shaded.
`
`space. With RPC, passing pointers is impossible because the client and server are
`in different address spaces.
`In some cases, tricks can be used to make it possible to pass pointers. Sup(cid:173)
`pose that the first parameter is a pointer to an integer, k. The client stub can
`marshal k and send it along to the server. The server stub then creates a pointer to
`k and passes it to the server procedure, just as it expects. When the server pro(cid:173)
`cedure returns control to the server stub, the latter sends k back to the client where
`. the new k is copied over the old one, just in case the server changed it. In effect,
`the standard calling sequence of call-by-reference has been replaced by copy(cid:173)
`restore. Unfortunately, this trick does not always work, for example, if the pointer
`points to a graph or other complex data structure. For this reason, some restric(cid:173)
`tions must be placed on parameters to procedures called remotely.
`A second problem is that in weakly-typed languages, like C, it is perfectly
`legal to write a procedure that computes the inner product of two vectors (arrays),
`without specifying how large either one is. Each could be terminated by a special
`value known only to the calling and called procedure. Under these circumstances,
`it is essentially impossible for the client stub to marshal the parameters: it has no
`way of determining how large they are.
`A third problem is that it is not always possible to deduce the types of the
`parameters, not even from a formal specification or the code itself. An example is
`p rint!, which may have any number of parameters (at least one), and the parame(cid:173)
`ters can be an arbitrary mixture of integers, shorts, longs, characters, strings,
`floating-point numbers of various lengths, and other types. Trying to call printf as
`a remote procedure would be practically impossible because C is so permissive.
`However, a rule saying that RPC can be used provided that you do not program in
`C ( or C++) would not be popular.
`A fourth problem relates to the use of global variables. Normally, the calling
`and called procedure can communicate by using global variables, in addition to
`
`I
`
`/
`
`Page 10 of 27
`
`

`

`SEC. 6.4
`
`THE INTERNET TRANSPORT PROTOCOLS: UDP
`
`529
`
`communicating via parameters. If the called procedure is now moved to a remote
`machine, the code will fail because the global variables are no longer shared.
`These problems are not meant to suggest that RPC is hopeless. In fact, it is
`widely used, but some restrictions are needed to make it work well in practice.
`Of course, RPC need not use UDP packets, but RPC and UDP are a good fit
`and UDP is commonly used for RPC; However, when the parameters or results
`may be larger than the maximum UDP packet or when the operation requested is
`not idempotent (i.e., cannot be repeated safely, such as when incrementing a
`counter), it may be necessary to set up a TCP connection and send the request
`over it rather than use UDP.
`
`6.4.3 The Real-Time Transport Protocol
`
`Client-server RPC is one area in which UDP is widely used. Another one is
`real-time multimedia applications. In particular, as Internet radio, Internet tele(cid:173)
`phony, music-on-demand, videoconferencing, video-on-demand, and other multi(cid:173)
`media applications became more commonplace, people discovered that each ap(cid:173)
`plication was reinventing more or less the same real-time transport protocol. It
`gradually became clear that having a generic real-time transport protocol for mul(cid:173)
`tiple applications would be a good idea. Thus was RTP (Real-time Transport
`Protocol) born. It is described in RFC 1889 and is now in widespread use.
`The position of RTP in the protocol stack is somewhat strange. It was
`decided to put RTP in user space and have it (normally) run over UDP. It oper(cid:173)
`ates as follows. The multimedia application consists of multiple audio, video,
`text, and possibly other streams. These are fed into the RTP library, which is in
`user space along with the application. This library then multiplexes the streams
`and encodes them in RTP packets, which it then stuffs into a socket. At the other
`end of the socket (in the operating system kernel), UDP packets are generated and
`embedded in IP packets. If the computer is on an Ethernet, the IP packets are then
`put in Ethernet frames for transmission. The protocol stack for this situation is
`shown in Fig. 6-25(a). The packet nesting is shown in Fig. 6-25(b).
`
`Socket interface
`
`UDP
`
`Ker~~ 1--- --IP _ __ -i
`{
`Ethernet
`
`(a)
`
`Ethernet
`header
`+
`
`ATP
`UDP
`IP
`header header header
`I
`!
`j
`
`I I I I
`
`ATP P1:1-Yload
`
`I
`
`-UDP payload-
`
`IP payload
`
`Ethernet payload
`
`(b)
`
`Figure 6-25. (a) The position of RTP in the protocol stack. (b) Packet nesting.
`
`Page 11 of 27
`
`

`

`530
`
`THE TRANSPORT LA YER
`
`CHAP. 6
`
`As a consequence of this design, it is a little hard to say which layer RTP is
`in. Since it runs in user space and is linked to the application program, it certainly
`looks like an application protocol. On the other hand, it is a generic, application(cid:173)
`independent protocol that just provides transport facilities, so it also looks like a
`transport protocol. Probably the best description is that it is a transport protocol
`that is implemented in the application layer.
`The basic function of RTP is to multiplex several real-time data streams onto
`a single stream of UDP packets. The UDP stream can be sent to a single destina(cid:173)
`tion (unicasting) or to multiple destinations (multicasting). Because RTP just uses
`normal UDP, its packets are not treated specially by the routers unless some nor(cid:173)
`mal IP quality-of-service features are enabled. In particular, there are no special
`guarantees about delivery, jitter, etc.
`Each packet sent in an RTP stream is given a number one higher than its pred(cid:173)
`ecessor. This numbering allows the destination to determine if any packets are
`missing. If a packet is missing, the best action for the destination to take is to
`approximate the missing value by interpolation. Retransmission is not a practical
`option since the retransmitted packet would probably arrive too late to be useful.
`As a consequence, RTP has no flow control, no error control, no acknowledge(cid:173)
`ments, and no mechanism to request retransmissions.
`Each RTP payload may contain multiple samples, and they may be coded any
`way that the application wants. To allow for interworking, RTP defines several
`profiles (e.g., a single audio stream), and for each profile, multiple encoding for(cid:173)
`mats may be allowed. For example, a single audio stream may be encoded as 8-
`bit PCM samples at 8 kHz, delta encoding, predictive encoding, GSM encoding,
`MP3, and so on. RTP provides a header field in which the source can specify the
`encoding but is otherwise not involved in how encoding is done.
`Another facility many real-time applications need is timestamping. The idea
`here is to allow the source to associate a timestamp with the first sample in each
`packet. The timestamps are relative to the start of the stream, so only the differ(cid:173)
`ences between timestamps are significant. The absolute values have no meaning.
`This mechanism allows the destination to do a small amount of buffering and play
`each sample the right number of milliseconds after the start of the stream, inde(cid:173)
`pendently of when the packet containing the sample arrived. Not only does time(cid:173)
`stamping reduce the effects of jitter, but it also allows multiple streams to be syn(cid:173)
`chronized with each other. For example, a digital television program might have
`a video stream and two audio streams. The two audio streams could be for stereo
`broadcasts or for handling films with an original language soundtrack and a
`soundtrack dubbed into the local language, giving the viewer a choice. Each
`stream comes from a different physical device, but if they are timestamped from a
`single counter, they can be played back synchronously, even if the streams are
`transmitted somewhat erratically.
`The RTP header is illustrated in Fig. 6-26. It consists of three 32-bit words
`and potentially some extensions. The first word contains the Version field, which
`
`Page 12 of 27
`
`

`

`SEC. 6.4
`
`THE INTERNET TRANSPORT PROTOCOLS: UDP
`
`531
`
`is already at 2. Let us hope this version is very close to the ultimate version since
`there is only one code point left (although 3 could be defined as meaning that the
`real version was in an extension word).
`
`- - - -- - ----"- - - --32 bits - - --
`-
`-
`-
`- - - - -- -
`I I I I I I I I I I I I I I I I I I I I I I I I I I I I I I I I I
`Ver, I P I X I cc
`
`Sequence number
`
`!Ml
`
`Payload type I
`
`Timestamp
`
`Synchronization source identifier
`
`I
`
`l
`~
`I
`I
`
`!
`~
`I
`~--------------------------------------------------------------------~
`I
`I
`I
`:
`. Contributing source identifier
`:
`I
`I
`'------ - --- ---- ------ ------- ----- ---- - - ----- ---------- --- - -- ------ - ---- 1
`
`Figure 6-26. The RTP header.
`
`The P bit indicates that the packet has been padded to a multiple of 4 bytes.
`The last padding byte tells how many bytes were added. The X bit indicates that
`an extension header is present. The format and meaning of the extension header
`are not defined. The only thing that is defined is that the first word of the exten(cid:173)
`sion gives the length. This is an escape hatch for any unforeseen requirements.
`The CC field tells how many contributing sources are present, from O to 15
`(see below). The M bit is an application-specific marker bit. It can be used to
`mark the start of a video frame, the start of a word in an audio channel, or some(cid:173)
`thing else that the application understands. The Payload type field tells which en(cid:173)
`coding algorithm has been used (e.g., uncompressed 8-bit audio, MP3, etc.).
`Since every packet carries this field, the encoding can change during transmission.
`The Sequence number is just a counter that is incremented on each RTP packet
`sent. It is used to detect lost packets.
`The timestamp is produced by the stream's source to note when the first sam(cid:173)
`ple in the packet was made. This value can help reduce jitter at the receiver by
`decoupling the playback from the packet arrival time. The Synchronization
`source identifier tells which stream the packet belongs to. It is the method used to
`multiplex and demultiplex multiple data streams onto a single stream of UDP
`packets. Finally, the Contributing source identifiers, if any, are used when mixers
`are present in the studio. In that case, the mixer is the synchronizing source, and
`the streams being mixed are listed here.
`RTP has a little sister protocol (little sibling protocol?) called RTCP (Real(cid:173)
`time Transport Control Protocol). It handles feedback, synchronization, and
`the user interface but does not transport any data. The first function can be used
`
`Page 13 of 27
`
`

`

`532
`
`THE TRANSPORT LAYER
`
`CHAP. 6
`
`to provide feedback on delay, jitter, bandwidth, congestion, and other network
`properties to the sources. This infotmation can be used by the encoding process
`to increase the data rate (and give better quality) when the network is functioning
`well and to cut back the data rate when there is trouble in the network. By provid(cid:173)
`ing continuous feedback, the encoding algorithms can be continuously adapted to
`provide the best quality possible under the cun-ent circumstances. For example, if
`the bandwidth increases or deueases uuriug lhe transmission, the encoding may
`switch trom MP3 to 8-bit PCM to delta encoding as required. The Payload typP.
`field is used to tell the destination what encoding algorithm is used for the current
`packet, making it possible to vary it on demand.
`RTCP also handles interstream synchronization. The problem is that different
`streams may use different clocks, with different granularities and different drift
`rates. RTCP can be used to keep them in sync.
`Finally, RTCP provides a way for naming the various sources (e.g., in ASCII
`text). This information can be displayed on the receiver's screen to indicate who
`is talking at the moment.
`More information about RTP can be found in (Perkins, 2002).
`
`6.5 THE INTERNET TRANSPORT PROTOCOLS: TCP
`
`UDP is a simple protocol and it has some niche uses, such as client-server
`interactions and multimedia, but for most Internet applications, reliable, sequen(cid:173)
`ced delivery is needed. UDP cannot provide this, so another protocol is required.
`Tt is c;:illP.rl TCP and is the main worlrJ10rse of the Internet. Let us now study it in
`detail.
`
`6.5.1 Introduction to TCP
`
`TCP (Transmission Control Protocol) was specifically designed to provide
`a reliable end-to-end byte stream over an unreliable internetwork. An internet(cid:173)
`work differs from a single network because different parts may have wildly dif(cid:173)
`ferent topologies, bandwidths, delays, packet sizes, and other parameters. TCP
`was designed to dynamically adapt to properties of the internetwork and to be
`robust in the face of many kinds of failures.
`TCP was formally defined in RFC 793 . As time went on, various errors and
`inconsistencies were detected, and the requirements were changed in some areas.
`These clarifications and some bug fixes are detailed in RFC 1122. Extensions are
`given in RFC 1323.
`Each machine supporting TCP has a TCP transport entity, either a library pro(cid:173)
`cedure, a user process, or part of the kernel. In all cases, it manages TCP streams
`and interfaces to the IP layer. "A TCP entity accepts user data streams from local
`processes, breaks them up into pieces not exceeding 64 KB (in practice, often
`
`Page 14 of 27
`
`

`

`SEC. 6.5
`
`THE INTERNET TRANSPORT PROTOCOLS: TCP
`
`533
`
`1460 data bytes in order to fit in a single Ethernet frame with the IP and TCP
`headers), and sends each piece as a separate IP datagram. When datagrams con(cid:173)
`taining TCP data arrive at a machine, they are given to the TCP entity, which re(cid:173)
`constructs the original byte streams. For simplicity, we will sometimes use just
`"TCP" to mean the TCP transport entity (a piece of software) or the TCP proto(cid:173)
`col (a set of rules). From the context it will be clear which is meant. For example,
`in "The user gives TCP the data," the TCP transport entity is clearly intended.
`The IP layer gives no guarantee that datagrams will be delivered properly, so
`it is up to TCP to time out and retransmit them as need be. Datagrams that do
`arrive may well do so in the wrong order; it is also up to TCP to reassemble them
`into messages in the proper sequence. In short, TCP must furnish the reliability
`that most users want and that IP does not provide.
`
`6.5.2 The TCP Service Model
`
`TCP service is obtained by both the sender and receiver creating end points,
`called sockets, as discussed in Sec. 6.1.3. Each socket has a socket number
`(address) consisting of the IP address of the host and a 16-bit number local to that
`host, called a port. A port is the TCP name for a TSAP. For TCP service to be
`obtained, a connection must be explicitly established between a socket on the
`sending machine and a socket on the receiving machine. The socket calls are
`listed in Fig. 6-5.
`A socket may be used for multiple connections at the same time. In other
`words, two or more connections may terminate at the same socket. Connections
`are identified by the socket identifiers at both ends, that is, (socket], socket2). No
`virtual circuit numbers or other identifiers are used.
`Port numbers below 1024 are called well-known ports and are reserved for
`standard services. For example, any process wishing to establish a connection to
`a host to transfer a file using FTP can connect to the destination host's port 21 to
`contact its FTP daemon. The list of well-known ports is given at www.iana.org.
`Over 300 have been assigned. A few of the better known ones are listed in
`Fig. 6-27.
`It would certainly be possible to have the FTP daemon attach itself to port 21
`at boot time, the telnet daemon to attach itself to port 23 at boot time, and so on.
`However, doing so would clutter up memory with daemons that were idle most of
`the time. Instead, what is generally done is to have a single daemon, called inetd
`(Internet daemon) in UNIX, attach itself to multiple ports and wait for the first
`incoming connection. When that occurs, inetd forks off a new process and exe(cid:173)
`cutes the appropriate daemon in it, letting that daemon handle the request. In this
`way, the daemons other than inetd are only active when there is work for them to
`do. Inetd learns which ports it is to use from a configuration file. Consequently,
`the system administrator can set up the system to have permanent daemons on the
`busiest ports (e.g., port 80) and inetd on the rest.
`
`Page 15 of 27
`
`

`

`534
`
`.THE TRANSPORT LA YER
`
`CHAP. 6
`
`Port Protocol
`21
`FTP
`Telnet
`23
`25
`SMTP
`TFTP
`69
`Finger
`79
`HTTP
`80
`POP-3
`110
`119
`NNTP
`
`Use
`
`File transfer
`Remote login
`E-mail
`Trivial file transfer protocol
`Lookup information about a user
`World Wide Web
`Remote e-mail access
`USENET news
`
`Figure 6-27. Some assigned ports.
`
`All TCP connections are full duplex and point-to-point. Full duplex means
`that traffic can go in both directions at the same time. Point-to-point means that
`each connection