Föreläsning 2: Applikationslagret

Download Report

Transcript Föreläsning 2: Applikationslagret

Centralized Architectures
• Figure 2-3. General interaction between a client
and a server.
Server design issues
• Server organization
– Iterative
– Concurrent
• Multithreaded
• Fork (unix)
– Stateless or stateful
• Client contact: End point (port)
– Well-known
– Dynamic: daemon; superserver (unix)
End Point, General Design Issues
(1)
• Figure 3-11. (a) Client-to-server binding using a
daemon.
End Point, General Design Issues
(2)
• Figure 3-11. (b) Client-to-server binding using a
superserver.
Server Clusters (1)
• Figure 3-12. The general organization of a
three-tiered server cluster.
Tanenbaum & Van Steen, Distributed
Systems: Principles and Paradigms, 2e, (c)
2007 Prentice-Hall, Inc. All rights reserved.
Server Clusters (2)
• Figure 3-13. The principle of TCP handoff.
Tanenbaum & Van Steen, Distributed
Systems: Principles and Paradigms, 2e, (c)
2007 Prentice-Hall, Inc. All rights reserved.
Sockets: Processes in different hosts
communicating
•process sends/receives
messages to/from its socket
•socket analogous to door
– sending process shoves
message out door
– sending process relies on
transport infrastructure
on other side of door
which brings message to
socket at receiving
process
host or
server
host or
server
process
controlled by
app developer
process
socket
socket
TCP with
buffers,
variables
Internet
TCP with
buffers,
variables
controlled
by OS
API: (1) choice of transport protocol;
(2) ability to fix a few parameters. How to address processes?
TDTS04 Lecture 2: Application layer and transport
2009-08-28
7
Berkeley Sockets
• Figure 4-14. The socket primitives for TCP/IP.
Tanenbaum & Van Steen, Distributed
Systems: Principles and Paradigms, 2e, (c)
2007 Prentice-Hall, Inc. All rights reserved.
Connection-oriented socket (tcp)
• Figure 4-15. Connection-oriented communication
pattern using sockets.
Tanenbaum & Van Steen, Distributed
Systems: Principles and Paradigms, 2e, (c)
2007 Prentice-Hall, Inc. All rights reserved.
Clock Synchronization
• Figure 6-1. When each machine has its own
clock, an event that occurred after another
event may nevertheless be assigned an earlier
Physical Clocks (2)
• Figure 6-3. TAI seconds are of constant length,
unlike solar seconds. Leap seconds are introduced
when necessary to keep in phase with the sun.
Lamport’s Logical Clocks (1978)(1)
• The "happens-before" relation → can be
observed directly in two situations:
• If a and b are events in the same process, and a
occurs before b, then a → b is true.
• If a is the event of a message being sent by one
process, and b is the event of the message being
received by another process, then a → b
Lamport’s Logical Clocks (2)
• Figure 6-9. (a) Three processes, each with its
own clock.
The clocks run at different rates.
Lamport’s Logical Clocks (3)
• Figure 6-9. (b) Lamport’s algorithm corrects the
clocks.
Lamport’s Logical Clocks (4)
• Figure 6-10. The positioning of Lamport’s
logical
clocks in distributed systems.
Lamport’s Logical Clocks (5)
• Updating counter Ci for process Pi
1. Before executing an event Pi executes
Ci ← Ci + 1.
2. When process Pi sends a message m to Pj, it sets m’s
timestamp ts (m) equal to Ci after having executed the
previous step.
3. Upon the receipt of a message m, process Pj adjusts its
own local counter as
Cj ← max{Cj , ts (m)}, after which it then executes the
first step and delivers the message to the application.
Middleware Protocols
• Figure 4-3. An adapted reference model
for networked communication.
Tanenbaum & Van Steen, Distributed
Systems: Principles and Paradigms, 2e, (c)
2007 Prentice-Hall, Inc. All rights reserved.
Types of Communication
• Figure 4-4. Viewing middleware as an
intermediate (distributed) service in
application-level communication.
Tanenbaum & Van Steen, Distributed
Systems: Principles and Paradigms, 2e, (c)
2007 Prentice-Hall, Inc. All rights reserved.
Client and Server Stubs
• Figure 4-6. Principle of RPC between a client and
server program.
Tanenbaum & Van Steen, Distributed
Systems: Principles and Paradigms, 2e, (c)
2007 Prentice-Hall, Inc. All rights reserved.
Remote Procedure Calls (1)
• A remote procedure call occurs in the following
• steps:
1.The client procedure calls the client stub in the
normal way.
2.The client stub builds a message and calls the
local operating system.
3.The client’s OS sends the message to the
remote OS.
4.The remote OS gives the message to the server
stub.
Tanenbaum & Van Steen, Distributed
Systems: Principles and Paradigms, 2e, (c)
2007 Prentice-Hall, Inc. All rights reserved.
Remote Procedure Calls (2)
• A remote procedure call occurs in the following
• steps (continued):
6.The server does the work and returns the result
to the stub.
7.The server stub packs it in a message and calls
its local OS.
8.The server’s OS sends the message to the
client’s OS.
9.The client’s OS gives the message to the client
stub.
Tanenbaum & Van Steen, Distributed
Systems: Principles and Paradigms, 2e, (c)
2007 Prentice-Hall, Inc. All rights reserved.
Passing Value Parameters (1)
• Figure 4-7. The steps involved in a doing a
remote computation through RPC.
Tanenbaum & Van Steen, Distributed
Systems: Principles and Paradigms, 2e, (c)
2007 Prentice-Hall, Inc. All rights reserved.
Asynchronous RPC (2)
• Figure 4-10. (b) The interaction using
asynchronous RPC.
Tanenbaum & Van Steen, Distributed
Systems: Principles and Paradigms, 2e, (c)
2007 Prentice-Hall, Inc. All rights reserved.
Asynchronous RPC (3)
• Figure 4-11. A client and server interacting
through
two asynchronous RPCs.
Tanenbaum & Van Steen, Distributed
Systems: Principles and Paradigms, 2e, (c)
2007 Prentice-Hall, Inc. All rights reserved.