DISTRIBUTED SYSTEMS
`
`Vmwiples AM Vamdigms
`
`
`
`(cid:48)(cid:44)(cid:55)(cid:3)(cid:21)(cid:19)(cid:20)(cid:20)
`_MIT2011
`Andrew S.Tanenbaum _
`(cid:47)(cid:76)(cid:80)(cid:72)(cid:79)(cid:76)(cid:74)(cid:75)(cid:87)(cid:3)(cid:89)(cid:17)(cid:3)(cid:48)(cid:44)(cid:55)
`leellght v. MIT
`(cid:44)(cid:51)(cid:53)(cid:21)(cid:19)(cid:20)(cid:26)(cid:16)(cid:19)(cid:19)(cid:21)(cid:23)(cid:28)
`IPR2017-00249
`
`Second Edition
`
`Maarten1Van Steen
`1
`
`

`

`Library of Congress Cataloging-in—Publication Data
`
`Tanenbaum, Andrew S.
`Distributed systems : principles and paradigms / Andrew S. Tanenbaum, Maarten Van Steen.
`. cm.
`
`Includes bibliographical references and index.
`ISBN 0-13—239227-5
`1. Electronic data processing-Distributed processing. 2. Distributed operating systems (Computers)
`Maarten van.
`11. Title.
`QA76.9.D5T36 2006
`005.4' 476-—d022
`
`2006024063
`
`I. Steen,
`
`Vice President and Editorial Director, ECS: Marcia J. Horton
`Executive Editor: TracyDunkererger
`Editorial Assistant: Christianna Lee
`Associtate Editor: Carole Snyder
`Executive Managing Editor: Vince O’Brien
`Managing Editor: CamiIIe Trentacoste
`Production Editor: Craig Little
`Director of Creative Services: Paul Belfanti
`Creative Director: Juan Lopez
`Art Director: Heather Scott
`Cover Designer: Tamara Newnam
`Art Editor: Xiaohong Z11 11
`Manufacturing Manager, ESM: Alex‘s Heydt-Long
`Manufacturing Buyer: Lisa McDowell
`Executive Marketing Manager: Robin O’Brien
`Marketing Assistant: Mack Patterson
`
`i" I
`
`-‘\ ['1 ‘3 l' J 3'1
`
`
`
`© 2007 Pearson Education, Inc.
`Pearson Prentice Hall
`Pearson Education, Inc.
`Upper Saddle River, NJ 07458
`
`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.
`
`Pearson Prentice Hall” is a trademark of Pearson Education, Inc.
`
`The author and publisher of, this book have used their best efforts in preparing this book. These efforts include the
`development, research, and testing of the theories and programs to determine their effectiveness. The author and
`publisher make no warranty of any kind, expressed or implied, with regard to these programs or the documentation
`contained in this book. The author and publisher shall not be liable in any event for incidental or consequential
`damages in connection with, or arising out of, the furnishing, performance, or use of these programs.
`
`Printed in the United St ates of America
`
`10987654321
`
`ISBN: 0-13-239227-5
`
`Pearson Education Ltd, London
`Pearson Education Australia Pty. Ltd., Sydney
`Pearson Education Singapore, Pte. Ltd.
`Pearson Education North Asia Ltd., Hong Kong
`Pearson Education Canada, Inc., Toronto
`Pearson Educacién de Mexico, SA. de CV.
`Pearson Education—Japan, Tokyo
`Pearson Education Malaysia, Pte. Ltd.
`Pearson Education, Inc., Upper Saddle River, New Jersey
`
`2
`”away/0532
`
`——_____.—._—.~_._..__.
`
`I”
`
`

`

`CONTENTS
`
`PREFACE
`
`1
`
`INTRODUCTION
`
`xvii
`
`1
`
`1.1
`
`DEFINITION OF A DISTRIBUTED SYSTEM 2
`
`1.2
`
`GOALS 3
`
`1.2.1 Making Resources Accessible 3
`1.2.2 Distribution Transparency 4
`1.2.3 Openness 7
`1.2.4 Scalability 9
`1.2.5 Pitfalls
`16
`
`1.3
`
`TYPES OF DISTRIBUTED SYSTEMS 17
`
`17
`1.3.1 Distributed Computing Systems
`1.3.2 Distributed Information Systems 20
`1.3.3 Distributed Pervasive Systems 24
`
`1.4
`
`SUMMARY 30
`
`2 ARCHITECTURES
`
`33
`
`2.1
`
`ARCHITECTURAL STYLES 34
`
`2.2
`
`SYSTEM ARCHITECTURES 36
`
`2.2.1 Centralized Architectures 36
`
`2.2.2 Decentralized Architectures 43
`
`2.2.3 Hybrid Architectures 52
`
`2.3
`
`ARCHITECTURES VERSUS MIDDLEWARE 54
`
`2.3.1 Interceptors 55
`2.3.2 General Approaches to Adaptive Software 57
`2.3.3 Discussion 58
`
`vii
`
`3
`3
`
`

`

`—I—
`
`viii
`
`2.4
`
`CONTENTS
`
`SELF-MANAGEMENT IN DISTRIBUTED SYSTEMS 59
`2.4.1 The Feedback Control Model 60
`2.4.2 Example: Systems Monitoring with Astrolabe 61
`2.4.3 Example: Differentiating Replication Strategies in Globule 63
`2.4.4 Example: Automatic Component Repair Management in Jade 65
`
`2.5
`
`SUMMARY 66
`
`3
`
`PROCESSES
`
`69
`
`3.1
`
`THREADS 70
`3.1.1 Introduction to Threads 70
`3.1.2 Threads in Distributed Systems 75
`
`3.2 VIRTUALIZATION 79
`3.2.1 The Role of Virtualization in Distributed Systems 79
`3.2.2 Architectures of Virtual Machines 80
`
`3.3
`
`3.4
`
`3.5
`
`CLIENTS 82
`3.3.1 Networked User Interfaces 82
`3.3.2 Client-Side Software for Distribution Transparency 87
`
`SERVERS 88
`3.4.1 General Design Issues
`3.4.2 Server Clusters 92
`3.4.3 Managing Server Clusters 98
`
`88
`
`CODE MIGRATION 103
`3.5.1 Approaches to Code Migration 103
`3.5.2 Migration and Local Resources
`107
`3.5.3 Migration in Heterogeneous Systems
`
`110
`
`3.6
`
`SUMMARY 112
`
`4 COMMUNICATION
`
`115
`
`4.1
`
`4.2
`
`FUNDAMENTALS 116
`116
`4.1.1 Layered Protocols
`4.1.2 Types of Communication 124
`
`REMOTE PROCEDURE CALL 125
`4.2.1 Basic RPC Operation 126
`4.2.2 Parameter Passing 130
`
`4
`4
`
`

`

`CONTENTS
`
`iX
`
`4.2.3 Asynchronous RFC 134
`4.2.4 Example: DCE RFC 135
`
`4.3 MESSAGE-ORIENTED COMMUNICATION 140
`
`4.3.1 Message-Oriented Transient Communication 141
`4.3.2 Message—Oriented Persistent Communication 145
`4.3.3 Example: IBM’s WebSphere Message-Queuing System 152
`
`4.4
`
`STREAM-ORIENTED COMMUNICATION 157
`
`4.4.1 Support for Continuous Media 158
`4.4.2 Streams and Quality of Service
`160
`4.4.3 Stream Synchronization 163
`
`4.5 MULTICAST COMMUNICATION 166
`
`4.5.1 Application-Level Multicasting 166
`4.5.2 Gossip—Based Data Dissemination 170
`
`4.6
`
`SUMMARY 175
`
`5
`
`NAMING
`
`179
`
`5.1
`
`NAMES, IDENTIFIERS, AND ADDRESSES 180
`
`5.2
`
`FLAT NAMING 182
`
`183
`5.2.1 Simple Solutions
`5.2.2 Home—Based Approaches
`5.2.3 Distributed Hash Tables
`
`186
`188
`
`5.2.4 Hierarchical Approaches
`
`191
`
`5.3
`
`STRUCTURED NAMING 195
`
`195
`5.3.1 Name Spaces
`5.3.2 Name Resolution 198
`
`5.3.3 The Implementation of a Name Space 202
`5.3.4 Example: The Domain Name System 209
`
`5.4 ATTRIBUTE-BASED NAMING 217
`
`5.4.1 Directory Services 217
`5.4.2 Hierarchical Implementations: LDAP 218
`5.4.3 Decentralized Implementations 222
`
`5 .5
`
`SUMMARY
`
`5
`
`
`

`

`-"_"—"———'——————
`
`X
`
`6
`
`CONTENTS
`
`SYNCHRONIZATION
`
`231
`
`6.1
`
`6.2
`
`CLOCK SYNCHRONIZATION 232
`6.1.1 Physical Clocks 233
`6.1.2 Global Positioning System 236
`6.1.3 Clock Synchronization Algorithms 238
`
`LOGICAL CLOCKS 244
`6.2.1 Lamport’s Logical Clocks 244
`6.2.2 Vector Clocks 248
`
`6.3 MUTUAL EXCLUSION 252
`6.3.1 Overview 252
`6.3.2 A Centralized Algorithm 253
`6.3.3 A Decentralized Algorithm 254
`6.3.4 A Distributed Algorithm 255
`6.3.5 A Token Ring Algorithm 258
`6.3.6 A Comparison of the Four Algorithms 259
`
`6.4 GLOBAL POSITIONING OF NODES 260
`
`6.5
`
`ELECTION ALGORITHMS 263
`6.5.1 Traditional Election Algorithms 264
`6.5.2 Elections in Wireless Environments 267
`6.5.3 Elections in Large—Scale Systems 269
`
`6.6
`
`SUMMARY 270
`
`7
`
`CONSISTENCY AND REPLICATION
`
`273
`
`7.1
`
`INTRODUCTION 274
`7.1.1 Reasons for Replication 274
`7.1.2 Replication as Scaling Technique
`
`275
`
`7.2 DATA-CENTRIC CONSISTENCY MODELS 276
`7.2.1 Continuous Consistency 277
`7.2.2 Consistent Ordering of Operations 281
`
`7.3
`
`CLIENT-CENTRIC CONSISTENCY MODELS 288
`7.3.1 Eventual Consistency 289
`7.3.2 Monotonic Reads 291
`7.3.3 Monotonic Writes 292
`7.3.4 Read Your Writes 294
`7.3.5 Writes Follow Reads 295
`
`6
`
`

`

`CONTENTS
`
`Xi
`
`7.4
`
`REPLICA MANAGEMENT 296
`
`7.4.1 Replica-Server Placement 296
`7.4.2 Content Replication and Placement 298
`7.4.3 Content Distribution 302
`
`7.5
`
`CONSISTENCY PROTOCOLS 306
`
`7.5.1 Continuous Consistency 306
`7.5.2 Primary—Based Protocols 308
`7.5.3 Replicated—Write Protocols 311
`7.5.4 Cache—Coherence Protocols 313
`
`7.5.5 Implementing Client—Centric Consistency 315
`
`7.6
`
`SUMMARY 317
`
`8
`
`FAULT TOLERANCE
`
`321
`
`8.1
`
`INTRODUCTION TO FAULT TOLERANCE 322
`
`8.1.1 Basic Concepts 322
`8.1.2 Failure Models 324
`
`8.1.3 Failure Masking by Redundancy 326
`
`8.2
`
`PROCESS RESILIENCE 328
`
`73
`
`8.3
`
`8.2.1 Design Issues 328
`8.2.2 Failure Masking and Replication 330
`8.2.3 Agreement in Faulty Systems 331
`8.2.4 Failure Detection 335
`RELIABLE CLIENT-SERVER COMMUNICATION 336
`8.3.1 Point—to—Point Communication 337
`
`8.3.2 RPC Semantics in the Presence of Failures 337
`
`8.4
`
`RELIABLE GROUP COMMUNICATION 343
`
`8.4.1 Basic Reliable-Multicasting Schemes 343
`8.4.2 Scalability in Reliable Multicasting 345
`8.4.3 Atomic Multicast 348
`
`8.5
`
`DISTRIBUTED COMMIT 355
`
`8.5.1 Two—Phase Commit 355
`
`8.5.2 Three-Phase Commit 360
`
`8.6
`
`RECOVERY 363
`
`8.6.1 Introduction 363
`
`8.6.2 Checkpointing 366
`
`7
`7
`
`
`
`

`

`fl
`
`Xii
`
`CONTENTS
`
`8.6.3 Message Logging 369
`8.6.4 Recovery—Oriented Computing 372
`
`8.7
`
`SUMMARY 373
`
`9
`
`SECURITY
`
`377
`
`9.1
`
`9.2
`
`9.3
`
`9.4
`
`INTRODUCTION TO SECURITY 378
`9.1.1 Security Threats, Policies, and Mechanisms 378
`9.1.2 Design Issues 384
`9.1.3 Cryptography 389
`
`SECURE CHANNELS 396
`9.2.1 Authentication 397
`9.2.2 Message Integrity and Confidentiality 405
`9.2.3 Secure Group Communication 408
`9.2.4 Example: Kerberos 411
`
`ACCESS CONTROL 413
`9.3.1 General Issues in Access Control 414
`9.3.2 Firewalls 418
`9.3.3 Secure Mobile Code 420
`9.3.4 Denial of Service 427
`
`SECURITY MANAGEMENT 428
`9.4.1 Key Management 428
`9.4.2 Secure Group Management 433
`9.4.3 Authorization Management 434
`
`9.5
`
`SUMMARY 439
`
`10 DISTRIBUTED OBJECT-BASED SYSTEMS
`
`443
`
`10.1 ARCHITECTURE 443
`10.1.1 Distributed Objects 444
`10.1.2 Example: Enterprise Java Beans 446
`10.1.3 Example: Globe Distributed Shared Objects 448
`
`'
`
`10.2 PROCESSES 451
`10.2.1 Object Servers 451
`10.2.2 Example: The Ice Runtime System 454
`
`8
`8
`
`

`

`CONTENTS
`
`Xiii
`
`10.3 COMMUNICATION 456
`
`10.3.1 Binding a Client to an Object 456
`10.3.2 Static versus Dynamic Remote Method Invocations 458
`10.3.3 Parameter Passing 460
`10.3.4 Example: Java RMI 461
`10.3.5 Object—Based Messaging 464
`
`.
`10.4 NAMING 466
`10.4.1 CORBA Object References 467
`10.4.2 Globe Object References 469
`
`10.5 SYNCHRONIZATION 470
`
`10.6 CONSISTENCY AND REPLICATION 472
`
`10.6.1 Entry Consistency 472
`10.6.2 Replicated Invocations 475
`
`.
`10.7 FAULT TOLERANCE 477
`10.7.1 Example: Fault-Tolerant CORBA 477
`10.7.2 Example: Fault-Tolerant Java 480
`
`10.8 SECURITY 481
`
`10.8.1 Example: Globe 482
`10.8.2 Security for Remote Objects 486
`
`10.9 SUMMARY 487
`
`11 DISTRIBUTED FILE SYSTEMS
`
`491
`
`‘
`11.1 ARCHITECTURE 491
`11.1.1 Client—Server Architectures 491
`
`11.1.2 Cluster-Based Distributed File Systems 496
`11.1.3 Symmetric Architectures 499
`
`11.2 PROCESSES 501
`
`11.3 COMMUNICATION 502
`
`11.3.1 RPCs in NFS 502
`
`11.3.2 The RPC2 Subsystem 503
`11.3.3 File-Oriented Communication in Plan 9 505
`
`11.4 NAMING 506
`
`11.4.1 Naming in NFS 506
`11.4.2 Constructing a Global Name Space 512
`
`
`
`9
`9
`
`

`

`-—-————'—————
`
`XVi
`
`CONTENTS
`
`14 SUGGESTIONS FOR FURTHER READING
`
`623
`
`AND BIBLIOGRAPHY
`
`14.1 SUGGESTIONS FOR FURTHER READING 623
`14.1.1 Introduction and General Works 623
`
`14.1.2 Architectures 624
`
`14.1.3 Processes 625
`
`14.1.4 Communication 626
`
`14.1.5 Naming 626
`14.1.6 Synchronization 627
`14.1.7 Consistency and Replication 628
`14.1.8 Fault Tolerance 629
`
`14.1.9 Security 630
`14.1.10 Distributed Object-Based Systems 631
`14.1.11 Distributed File Systems 632
`14.1.12 Distributed Web-Based Systems 632
`14.1.13 Distributed Coordination—Based Systems 633 ,
`
`14,2 ALPHABETICAL BIBLIOGRAPHY 634
`
`INDEX
`
`669
`
`10
`10
`
`

`

`SEC. 12.6
`
`CONSISTENCY AND REPLICATION
`
`577
`
`
`(b)
`
`
`‘-—————Ii “6 days—-——'—““—*7‘ i
`
`
`
`
`
`(0)
`
`
`
`<———-—'.-
`
`2.5 days——---—*
`(d)
`
`Figure 12-19. One normal and three different access patterns reflecting flash-
`crowd behavior (adapted from Baryshnikov et a1., 2005).
`
`prediction for the number of requests. If the number of requests are predicted to
`exceed a given threshold, an alarm is raised.
`This method works remarkably well for multple access patterns. Unfortun-
`ately, the window size as well as determining what the alarm threshold are sup-
`posed to be depends highly on the Web server traffic. In practice, this means that
`much manual fine tuning is needed to configure an ideal predictor for a specific
`site. It is yet unknown how flash-crowd predictors can be automatically config-
`ured.
`
`Adjustment Measures
`
`As mentioned, there are essentially only three (related) measures that can be
`taken to change the behavior of a Web hosting service: changing the placement of
`replicas, changing consistency enforcement, and deciding on how and when to
`redirect client requests. We already discussed the first two measures extensively
`in Chap. 7. Client-request redirection deserves some more attention. Before we
`discuss some of the trade-offs, let us first consider how consistency and replica—
`tion are dealt with in a practical setting by considering the Akamai situation
`(Leighton and Lewin, 2000; and Dilley et a1., 2002).
`The basic idea is that each Web document consists of a main HTML (or
`XML) page in which several other documents such as images, Video, and audio
`
`
`
`11
`11
`
`

`

`
`
`578
`
`DISTRIBUTED WEB—BASED SYSTEMS
`
`CHAP. 12
`
`rn
`
`it is necessary that the
`have been embedded. To display the entire document,
`embedded documents are fetched by the user’s browser as well. The assumption is
`that these embedded documents rarely change, for which reason it makes sense to
`cache or replicate them.
`Each embedded document is normally referenced through a URL. However,
`in Akamai’s CDN, such a URL is modified such that it refers to a virtual ghost,
`which is a reference to an actual server in the CDN. The URL also contains the
`host name of the origin server for reasons we explain next. The modified URL is
`resolved as follows, as is also shown in Fig. 12—20.
`
`6. Get embedded documents
`(if not already cached)
`
`
`
`documents
`
`7. Embedded documents
`
`
`
`Return IP address
`
`client-best server
`1. Get base document
`
`
`CDN DNS
`server
`
`
`2. Document with refs
`
`to embedded documents
`
`Regular
`it
`: DNS system
`
`Figure 12-20. The principal working of the Akamai CDN.
`
`The name of the virtual ghost includes a DNS name such as ghostingcom,
`which is resolved by the regular DNS naming system to a CDN DNS server (the
`result of step 3). Each such DNS server keeps track of servers close to the client.
`To this end, any of the proximity metrics we have discussed previously could be
`used. In effect, the CDN DNS servers redirects the client to a replica server best
`for that client (step 4), which could mean the closest one, the least-loaded one, or
`a combination of several such metrics (the actual redirection policy is propri-
`
`etary).
`Finally, the client forwards the request for the embedded document to the Se-
`lected CDN server. If this server does not yet have the document, it fetches it
`from the original Web server (shown as step 6), caches it locally, and subse-
`quently passes it to the client. If the document was already in the CDN server S
`cache, it can be returned forthwith. Note that1n order to fetch the embedded docu—
`ment, the replica server must be able to send a request to the origin server, for
`which reason its host name is also contained in the embedded document’s URL.
`An interesting aspect of this scheme is the simplicity by which consistency 0f
`documents can be enforced. Clearly, whenever a main document is changed, a
`
`12
`12
`
`

`

`(v
`
`\v
`
`U1\Hu
`
`SEC. 12.6
`
`CONSISTENCY AND REPLICATION
`
`579
`
`client will always be able to fetch it from the origin server. In the case of embed—
`ded documents, a different approach needs to be followed as these documents are,
`in principle, fetched from a nearby replica server. To this end, a URL for an
`embedded document not only refers to a special host name that eventually leads to
`a CDN DNS server, but also contains a unique identifier that is changed every
`time the embedded document changes. In effect, this identifier changes the name
`of the embedded document. As a consequence, when the client is redirected to a
`specific CDN server, that server will not find the named document in its cache
`and will thus fetch it from the origin server. The old document will eventually be
`evicted from the server’s cache as it is no longer referenced.
`This example already shows the importance of client-request redirection. In
`principle, by properly redirecting clients, a CDN can stay in control when it
`comes to client-perceived performance, but also taking into account global system
`performance by, for example, avoiding that requests are sent to heavily loaded
`servers. These so—called adaptive redirection policies can be applied when infor-
`mation on the system’s current behavior is provided to the processes that take
`redirection decisions. This brings us partly back to the metric estimation tech—
`niques discussed previously.
`Besides the different policies, an important issue is whether request redirec—
`tion is transparent to the client or not. In essence, there are only three redirection
`techniques: TCP handoff, DNS redirection, and HTTP redirection. We already
`discussed TCP handoff. This technique is applicable only for server clusters and
`does not scale to wide—area networks.
`DNS redirection is a transparent mechanism by which the client can be kept
`completely unaware of where documents are located. Akamai’s two—level redirec-
`tion is one example of this technique. We can also directly deploy DNS to return
`one of several addresses as we discussed before. Note, however, that DNS re-
`direction can be applied only to an entire site: the name of individual documents
`does not fit into the DNS name space.
`HTTP redirection, finally, is a nontransparent mechanism. When a client re-
`quests a specific document, it may be given an alternative URL as part of an
`HTTP response message to which it is then redirected. An important observation
`is that this URL is visible to the client’s browser. In fact, the user may decide to
`bookmark the referral URL, potentially rendering the redirection policy useless.
`
`12.6.3 Replication of Web Applications
`
`Up to this point we have mainly concentrated on caching and replicating static
`Web content. In practice, we see that the Web is increasingly offering more
`dynamically generated content, but that it is also expanding toward offering ser-
`vices that can be called by remote applications. Also in these situations we see
`that caching and replication can help considerably in improving the overall
`
`
`
`13
`13
`
`

`

`SEC. 14.2
`
`ALPHABETICAL BIBLIOGRAPHY
`
`651
`
`“The Case for Reflective
`and BLAIR, G.:
`KON, F., COSTA, F., CAMPBELL, R.,
`Middleware.” Commun. ACM, (45)6:33—38, June 2002. Cited on page 57.
`
`KOPETZ, H. and VERISSIMO,P.: “Real Time and Dependability Concepts.” In Mul-
`lender, S. (ed.), Distributed Systems, pp. 411—446. Wokingham: Addison—Wesley, 2nd ed.,
`1993. Cited on page 322.
`
`KOSTOULAS, M. G., MATSA, M., MENDELSOHN, N., PERKINS, E., HEIFETS, A., and
`MERCALDI, M.: “XML Screamer: An Integrated Approach to High Performance XML
`Parsing, Validation and Deserialization.” Proc. 15th Int’l WWW Conf, (Edinburgh, Scot—
`land). New York, NY: ACM Press, 2006. Cited on page 567.
`
`KUMAR, P. and SATYANARAYANAN, M.: “Flexible and Safe Resolution of File Con-
`flicts.” Proc. Winter Techn. Conf. USENIX, 1995. pp. 95—106. Cited on page 526.
`
`LAI, A. and NIEH, J.: “Limits of Wide—Area Thin—Client Computing.” Proc. Int’l Conf.
`Measurements and Modeling of Computer Systems, (Marina Del Rey, CA). New York,
`NY: ACM Press, 2002. pp. 228-239. Cited on page 84.
`
`LAMACCHIA, B. and ODLYZKO,A.: “Computation of Discrete Logarithms in Prime
`Fields.” Designs, Codes, and Cryptography, (1)1:47-62, May 1991. Cited on page 534.
`
`LAMPORT, L.: “Time, Clocks, and the Ordering of Events in a Distributed System.”
`Commun. ACM, (21)7:558-565, July 1978. Cited on page 244.
`
`LAMPORT, L.: “How to Make a Multiprocessor Computer that Correctly Executes Mul-
`tiprocessor Programs.” IEEE Trans. Comp., (C-29)9:690—691, Sept. 1979. Cited on page
`282.
`
`LAMPORT, L., SHOSTAK, R., and PAESE, M.: “Byzantine Generals Problem.” ACM
`Trans. Prog. Lang. Syst., (4)3:382—401, July 1982. Cited on pages 326, 332, 334.
`
`LAMPSON, B., ABADI, M., BURROWS, M., and WOBBER, E.: “Authentication in Distri—
`buted Systems: Theory and Practice.” ACM Trans. Comp. Syst,
`(10)4:265—310, Nov.
`1992. Cited on page 397.
`
`LAPRIE, J.-C.: “Dependability — Its Attributes, Impairments and Means.” In Randell, B.,
`Laprie, J.—C., Kopetz, H., and Littlewood, B. (eds), Predictably Dependable Computing
`Systems, pp. 3—24. Berlin: Springer—Verlag, 1995. Cited on page 378.
`
`LAURIE, B. and LAURIE, P.: Apache: The Definitive Guide. Sebastopol, CA: O’Reilly &
`Associates, 3rd ed., 2002. Cited on page 558.
`
`LEFF, A. and RAYFIELD, J. T.: “Alternative Edge-server Architectures for Enterprise
`JavaBeans Applications.” Proc. Middleware 2004, vol. 3231 of Lect. Notes Comp. Sc.,
`(Toronto, Canada). Berlin: Springer—Verlag, 2004. pp. 195—211. Cited on page 52.
`
`LEIGHTON, F. and LEWIN, D.: “Global Hosting System.” United States Patent, Number
`6,108,703, Aug. 2000. Cited on page 577.
`
`LEVIEN, R. (ed.): Signposts in Cyberspace: The Domain Name System and Internet Navi-
`gation. Washington, DC: National Academic Research Council, 2005. Cited on page 210.
`
`LEVINE, B. and GARCIA-LUNA-ACEVES, J .: “A Comparison of Reliable Multicast Pro-
`tocols.” ACM Multimedia Systems Journal, (6)5:334—348, 1998. Cited on page 345.
`
`
`
`14
`14
`
`