.
`
`‘
`
`_,,
`
`,5 Le
`
`ERSON 8. BRUCE S;/ED
`
`.
`
`5
`;’
`
`$.21
`
`A SYSTEMS APPROACH
`
`Hughes V. Elbit, IPR2016-00135
`ELBIT EX. 2001 - 1/6
`
`Hughes v. Elbit, IPR2016-00135
`ELBIT EX. 2001 - 1/6
`
`

`
`SEEUNDEIJIHUN
`
`UIVI
`
`UT
`
`W
`
`A Systems Approach
`
`ELBIT EX. 2001 — 2/6
`
`Hughes V. Elbit, IPR2016-00135
`
`Hughes v. Elbit, IPR2016-00135
`ELBIT EX. 2001 - 2/6
`
`

`
`
`
`Computer Networks: A Systems Approach, 2e
`Larry L. Peterson and Bruce S. Davie
`High-Performance Communication Networks, Ze
`Jean Walrand and Pravin Varaiya
`lnternetworking Multimedia
`Jon Crowcroft, Mark Handley, and Ian Wakeman
`Understanding Networked Applications: A First Course
`David G. Messerschmitt
`Integrated Management of Networked Systems: Concepts, Architectures, and their
`Operational Application
`Heinz-Gerd Hegering, Sebastian Abeck, and Bernhard Neumair
`Virtual Private Networks: Making the Right Connection
`Dennis Fowler
`Networked Applications: A Guide to the New Computing Infrastructure
`David G. Messerschmitt
`Modern Cable Television Technology: Video, Voice, and Data Communications
`Walter Ciciora, James Farmer, and David Large
`Switching in IP Networks: IP Switching, Tag Switching, and Related Technologies
`Bruce S. Davie, Paul Doolan, and Yakov Rekhter
`Wide Area Network Design: Concepts and Tools for Optimization
`Robert S. Cahn
`
`The Morgan Kaufmann Series in Networking
`Series Editor, David Clark
`
`Optical Networks: A Practical Perspective
`Rajiv Ramaswami and Kumar Sivarajan
`Practical Computer Network Analysis and Design
`James D. McCabe
`Frame Relay Applications: Business and Technology Case Studies
`James P. Cavanagh
`
`For a list of forthcoming titles, please visit our Web site at
`http://www.mkp.com/publish/mann/networking.htm
`
`Hughes V. Elbit, IPR2016-00135
`ELBIT EX. 2001 - 3/6
`
`Hughes v. Elbit, IPR2016-00135
`ELBIT EX. 2001 - 3/6
`
`

`
`SEEUNIJEDIHDN
`
`Larry L. Peterson 85 Bruce 8. Davie
`
`UIVI
`
`UT
`
`A Systems Approach
`
`B1 If
`MORGAN KAUFMANN PUBLISHERS
`AN IMPRINT OF ACADEMIC PRESS
`A Harcourt Science and Technology Company
`s A N F R A N C I S C O
`s A N U I E G G
`N E w V o A K
`a O s Y ON
`L D N D D N
`5 Y D N E Y
`T D K YD
`
`ELBIT EX. 2001 - 4/6
`
`Hughes V. Elbit, IPR2016-00135
`
`Hughes v. Elbit, IPR2016-00135
`ELBIT EX. 2001 - 4/6
`
`

`
`L
`
`V
`
`Jennifer Mann
`Senior Editor
`Director of Production and Manufacturing Yonie Overton
`Production Editor Cheri Palmer
`Editorial Assistant Karyn Johnson
`Cover and Text Design Ross Carron Design
`Cover Image Alain Choisnet/ ImageBan1<
`Normandy Bridge at Night, Normandy, France
`Composition/Illustration Windfall Software, using ZZTEX
`Copyeditor Ken DellaPenta
`Proofreader
`Jennifer McClain
`Indexer Steve Rath
`
`Printer Courier Corporation
`
`Designations used by companies to distinguish their products are often claimed as trade-
`marks or registered trademarks. In all instances where Morgan Kaufmann Publishers is
`aware of a claim, the product names appear in initial capital or all capital letters. Read-
`ers, however, should contact the appropriate companies for more complete information
`regarding trademarks and registration.
`ACADEMIC PRESS
`
`A Harcourt Science and Technology Company
`525 B Street, Suite 1900, San Diego, CA 92101-4495, USA
`bttp://wwuzacademicpress.com
`Academic Press
`Harcourt Place, 32 Jamestown Road, London, NW1 7BY United Kingdom
`/attp://www.bbz1k.co.u/z/ap/
`
`Morgan Kaufmann Publishers
`340 Pine Street, Sixth Floor, San Francisco, CA 94104-3205, USA
`/Jttp://wu/w.rn/ep.com
`
`© 1996, 2000 by Academic Press
`All rights reserved
`Published 1996. Second Edition 2000
`Printed in the United States of America
`
`0403020100 5432
`
`No part of this publication may be reproduced, stored in a retrieval system, or transmit-
`ted in any form or by any means—electronic, mechanical, photocopying, recording, or
`otherwise—without the prior written permission of the publisher.
`
`Library of Congress Cataloging-in-Publication Data
`
`Peterson, Larry L.
`Computer networks : a systems approach / Larry L. Peterson 86 Bruce
`S. Davie. — 2nd ed.
`p.
`cm.
`
`Includes bibliographical references.
`ISBN 1-55860-514-2 (cloth). — ISBN 1-55860-577-0 (paper)
`1. Computer networks.
`I. Davie, Bruce S.
`II. Title.
`TK5'lO5.5.P479
`2000
`004.6/5—ClC21
`,
`_
`_
`,
`This book is printed on acid-free paper.
`
`99-36400
`CIP
`
`ELBIT EX. 2001 — 5/6
`
`Hughes V. Elbit, IPR2016-00135
`
`Hughes v. Elbit, IPR2016-00135
`ELBIT EX. 2001 - 5/6
`
`

`
`41 2
`
`5 End-to-End Protocols
`
`2
`
`*
`
`suitable value for RETRANSMIT is similar to the problem faced by TCP. Thus, CHAN
`
`that Variable. If CHAN is expected to run over the Internet, however, then selecting a
`
`would calculate the RETRANSMIT timeout using a mechanism similar to the one
`described in Section 5.2.5. The only difference is that CHAN has to take into account
`
`the fact that the message it is sending ranges in size from 1 B to 32 KB, whereas TCP
`is always transmitting segments of approximately the same size.
`
`Synchronous versus Asynchronous Protocols
`
`One way to characterize a protocol is by whether it is synchronous or async/aronous.
`These two terms have significantly different meanings, depending on where in the
`protocol hierarchy you use them. At the transport layer, it is most accurate to think
`of synchrony as a spectrum of possibilities rather than as two alternatives, where the
`key attribute of any point along the spectrum is how much the sender knows, after the
`operation to send a message returns. In other words, if we assume that an application
`program invokes a send operation on a transport protocol, then the question is, exactly
`what does the application know about the success of the operation when the send
`operation returns?
`the application knows absolutely
`At the asynchronous end of the spectrum,
`nothing when send returns. It not only doesn’t know if the message was received by
`its peer, but it doesn’t even know for sure that the message has successfully left the
`local machine. At the synchronous end of the spectrum, the send operation typically
`returns a reply message. That is, the application not only knows that the message it
`sent was received by its peer, but it knows that the peer has returned an answer. Thus,
`synchronous protocols implement the request/reply abstraction, while asynchronous
`protocols are used if the sender wants to be able to transmit many messages without
`having to wait for a response. Using this definition, CHAN is obviously a synchronous
`protocol.
`Although we have not discussed them in this chapter, there are interesting points
`between these two extremes. For example, the transport protocol might implement
`send so that it blocks (does not return) until the message has been successfully received
`at the remote machine, but returns before the sender’s peer on that machine has
`actually processed and responded to it. This is sometimes called a reliable datagram
`protocol.
`
`Implementation of CHAN
`
`We conclude our discussion of CHAN by giving fragments of C code that implement
`its client side. Since CHAN exports a synchronous interface to higher-level protocols-
`the caller blocks until a reply can be returned———the send operation we have been using
`is not going to work. Therefore, we introduce a new interface operation, which we
`
`l
`l
`l
`l
`
`l
`l
`
`W
`
`V
`
`i
`
`l
`
`[
`
`;
`
`:*
`
`‘
`
`‘
`
`1
`
`ELBIT EX. 2001 — 6/6
`
`Hughes V. Elbit, IPR2016-00135
`
`Hughes v. Elbit, IPR2016-00135
`ELBIT EX. 2001 - 6/6