CS 43: Computer Networks. 08:Network Services and Distributed Systems 19 September

CS 43: Computer Networks 08:Network Services and Distributed Systems 19 September

Reading Quiz Lecture 8 -Slide 2

Last class Inter-process communication using message passing How send and recv buffers work Concurrency Multi-threading vs. multiple processes select() system call Lecture 8 -Slide 3

Today Distributed network applications Pros/Cons of: Client-Server Peer-to-peer architecture Sources of complexity Lecture 8 -Slide 4

What is a distributed application? Computer Computer Computer Network processes messages Computer Computer Cooperating processes in a computer network Varying degrees of integration Loose: email, web browsing Medium: chat, Skype, remote execution, remote file systems Tight: process migration, distributed file systems Lecture 8 -Slide 5

Inter-process Communication (IPC) In order to cooperate, need to communicate Achieved via IPC: inter-process communication ability for a process to communicate with another Lecture 8 -Slide 6

Inter-process Communication (IPC) In order to cooperate, need to communicate Achieved via IPC: inter-process communication ability for a process to communicate with another On a single machine: Shared memory Text Data Text Data Stack P1 Stack P2 Lecture 8 -Slide 7

Inter-process Communication (IPC) In order to cooperate, need to communicate Achieved via IPC: interprocess communication ability for a process to communicate with another On a single machine: Shared memory Text Data Text Data Stack P1 Stack P2 Shared Segment Lecture 8 -Slide 8

Inter-process Communication (IPC) In order to cooperate, need to communicate Achieved via IPC: interprocess communication ability for a process to communicate with another On a single machine: Shared memory Text Data Text Data Stack Stack Shared Segment Across machines: P1 P2 We need other abstractions (message passing) Lecture 8 -Slide 9

Sockets Process sends/receives messages to/from its socket Application has a few options, operating system handles the details Choice of transport protocol (TCP, UDP, ICMP, SCTP, etc.) Transport options (TCP: maximum segment size, delayed sends) application process socket application process controlled by app developer transport network link physical Internet transport network link physical controlled by OS Lecture 8 -Slide 10

Sockets Process sends/receives messages to/from its socket Application has a few options, operating system handles the details Choice of transport protocol (TCP, UDP, ICMP, SCTP, etc.) Transport options (TCP: maximum segment size, delayed sends) Must identify which socket we re addressing application process socket application process controlled by app developer transport network link physical Internet transport network link physical controlled by OS Lecture 8 -Slide 11

Addressing Sockets host App IP address identifies device interface host App TCP TCP router router IP IP IP IP Ethernet interface Ethernet interface SONET interface SONET interface Ethernet interface Ethernet interface Lecture 8 -Slide 12

Addressing Sockets host IP address identifies device interface host App TCP Need another identifier: port 16-bit, unsigned integer value Differentiates sockets App TCP router router IP IP IP IP Ethernet interface Ethernet interface SONET interface SONET interface Ethernet interface Ethernet interface Lecture 8 -Slide 13

Connection-oriented: example TCP socket identified by 4- tuple: source IP address source port number dest IP address dest port number Receiver uses all four values to direct segment to appropriate socket server host may support many simultaneous TCP sockets: each socket identified by its own 4-tuple web servers have different sockets for each connecting client non-persistent HTTP will have different socket for each request Lecture 8 -Slide 14

Connection-oriented: example application P3 transport network link physical P4 application P5 transport network link physical P6 server: IP address B application P2 P3 transport network link physical host: IP address A source IP,port: B,80 dest IP,port: A,9157 source IP,port: A,9157 dest IP, port: B,80 three segments, all destined to IP address: B, dest port: 80 are demultiplexed to different sockets source IP,port: C,5775 dest IP,port: B,80 source IP,port: C,9157 dest IP,port: B,80 host: IP address C Lecture 8 -Slide 15

Connection-oriented: example threaded server application P3 transport network link physical application P4 transport network link physical server: IP address B application P2 P3 transport network link physical host: IP address A source IP,port: B,80 dest IP,port: A,9157 source IP,port: C,5775 dest IP,port: B,80 host: IP address C source IP,port: A,9157 dest IP, port: B,80 source IP,port: C,9157 dest IP,port: B,80 Lecture 8 -Slide 16

Client/Server Model Client Internet Server Client Short-lived process that makes requests User-side of application Initiates the communication (often via connect()) Server Exports well-defined requests/response interface Long-lived process that waits for requests Upon receiving request, carries it out (may spawn processes) Lecture 8 -Slide 17

Client vs. Server Server: always-on host permanent (IP) address (rendezvous location) static port conventions (http:80, email:25, ssh:22) data centers for scaling may communicate with other servers to respond Clients: may be intermittently connected may have dynamic (IP) addresses do not communicate directly with each other Lecture 8 -Slide 18

Peer-to-Peer no always-on server arbitrary end systems directly communicate peers request service from other peers, provide service in return to other peers self scalability new peers bring new service capacity, as well as new service demands peers are intermittently connected and change IP addresses complex management peer-peer Lecture 8 -Slide 19

Peer-to-Peer Peer Peer A peer talks directly with another peer Symmetric responsibility (unlike client/server) Often used for: File sharing (Napster, BitTorrent) Games NoSQL data retrieval In general: distributed systems Lecture 8 -Slide 20

In a peer-to-peer architecture, are there clients and servers? A. Yes B. No Lecture 8 -Slide 21

Peer-to-Peer Peer Peer (+) Peers request service from other peers, provide service in return to other peers self scalability new peers bring new service capacity, as well as new service demands (-) Complex management, difficult problems Lecture 8 -Slide 22

Computer Advantages Computer Computer processes messages Network Computer Speed: parallelism, less contention Reliability: redundancy, fault tolerance Scalability: incremental growth, economy of scale Geographic distribution: low latency, reliability Lecture 8 -Slide 23

If one machine can process requests at a rate of X per second, how quickly can two machines process requests? A. Slower than one machine (<X) B. The same speed (X) C. Faster than one machine, but not double (X-2X) D. Twice as fast (2X) E. More than twice as fast(>2x) Lecture 8 -Slide 24

Computer Disadvantages Computer Computer processes messages Network Computer Fundamental problems of decentralized control State uncertainty: no shared memory or clock Action uncertainty: mutually conflicting decisions Distributed algorithms are complex Lecture 8 -Slide 25

On a single system You have a number of components CPU Memory Disk Power supply If any of these go wrong, you re (usually) toast. Lecture 8 -Slide 26

On multiple systems New classes of failures (partial failures). A link might fail One (of many) processes might fail The network might be partitioned Lecture 8 -Slide 27

On multiple systems New classes of failures (partial failures). A link might fail One (of many) processes might fail The network might be partitioned Introduces major complexity! Lecture 8 -Slide 28

If a process sends a message, can it tell the difference between a slow link and a delivery failure? Lecture 8 -Slide 29

If a process sends a message, can it tell the difference between a slow link and a delivery failure? A. Yes B. No Lecture 8 -Slide 30

What should we do to handle a partial failure? Under what circumstances, or what types of distributed applications? A. If one process fails or becomes unreachable, switch to a spare. B. Pause or shut down the application until all connectivity and processes are available. C. Allow the application to keep running, even if not all processes can communicate. D. Handle the failure in some other way. Lecture 8 -Slide 31

Desirable Properties Consistency Nodes agree on the distributed system s state Availability The system is able and willing to process requests Partition tolerance The system is robust to network (dis)connectivity Lecture 8 -Slide 32

The CAP Theorem Consistency Nodes agree on the distributed system s state Availability The system is able and willing to process requests Partition tolerance The system is robust to network (dis)connectivity Choose Two CAP prohibits only a tiny part of the design space: perfect availability and consistency in the presence of partitions, which are rare. * * Brewer, Eric. "CAP twelve years later: How the" rules" have changed." Computer 45.2 (2012): 23-29. Lecture 8 -Slide 33

Event Ordering It s very useful if all nodes can agree on the order of events in a distributed system For example: Two users trying to update a shared file across two replicas Lecture 8 -Slide 34

If two events occur (digitally or in the real world ), can we always tell which happened first? A. Yes B. No Relativity of simultaneity Example: observing car crashes Exception: causal relationship Lecture 8 -Slide 35

If two events occur (digitally or in the real world ), can we always tell which happened first? A. Yes B. No Relativity of simultaneity Example: observing car crashes Exception: causal relationship Lecture 8 -Slide 36

Event Ordering It s very useful if all nodes can agree on the order of events in a distributed system For example: Two users trying to update a shared file across two replicas Time, Clocks, and the Ordering of Events in a Distributed System by Leslie Lamport (1978) Establishes causal orderings Cited > 8000 times Lecture 8 -Slide 37

Causal Consistency Example Suppose we have the following scenario: Sally posts to Facebook, Billy is missing! (Billy is at a friend s house, sees message, calls mom) Sally posts new message, False alarm, he s fine Sally s friend James posts, What a relief! NOT causally consistent: Third user, Henry, sees only: Lecture 8 -Slide 38

Causal Consistency Example Suppose we have the following scenario: Sally posts to Facebook, Billy is missing! (Billy is at a friend s house, sees message, calls mom) Sally posts new message, False alarm, he s fine Sally s friend James posts, What a relief! NOT causally consistent: Third user, Henry, sees only: Lecture 8 -Slide 39

Causal Consistency Example Suppose we have the following scenario: Sally posts to Facebook, Billy is missing! (Billy is at a friend s house, sees message, calls mom) Sally posts new message, False alarm, he s fine Sally s friend James posts, What a relief! Causally consistent version: Third user, Henry, sees only: Because James had seen Sally s second post (which caused his response), Henry must also see it prior to seeing James s. Lecture 8 -Slide 40

Summary Client-server vs. peer-to-peer models Distributed systems are hard to build! Partial failures Ordering of events Take CS 87 for more details! Lecture 8 -Slide 41