1. 6/14/20151 System Models Chapter 2: Coulouris + Chapter notes from K. Birman’s that in turn was based on Professor Paul Francis notes, Cornell University

2. 6/14/20152 Distributed system models  Model: “a simplified representation of a system or phenomenon, as in the sciences or economics, with any hypotheses required to describe the system or explain the phenomenon, often mathematically.”

3. 6/14/20153 System Models  Architectural model defines the way in which the components of the system are placed and how they interact with one another and the way in which they are mapped onto the underlying network of computers.  Fundamental models: Interaction model deals with communication details among the components and their timing and performance details. Failure model gives specification of faults and defines reliable communication and correct processes. Security model specifies possible threats and defines the concept of secure channels.  We will discuss the various models at a high level in this discussion and will elaborate on each of these as we discuss other systems.

4. 6/14/20154 Architectural Model  Concerned with placement of its parts and relationship among them.  Example: client-server model, peer-to-peer model  Abstracts the functions of the individual components.  Defines patterns for distribution of data and workload.  Defines patterns of communication among the components.  Example: Definition of server process, client process and peer process and protocols for communication among processes; definition client/server model and its variations.

5. 6/14/20155 Software and hardware service layers in distributed systems

6. 7 National Weather Service Web Site Data Aggregator RMI WeatherInfo Server RMI WeatherInfo Client Application RMI IP Socket API Weather Web Service Web Client Analytics Weather Web Service Server Relation Database MySQL Http SOAP/REST XML LAN 1 2 3 4 5 6 Weather Google Map Client 7

7. 6/14/20157 Middleware  Layer of software whose purpose is to mask the heterogeneity and to provide a convenient programming model for application programmers.  Middleware supports such abstractions as remote method invocation, group communications, event notification, replication of shared data, real-time data streaming.  Examples: Java RMI, grid software (Globus, Open grid Services), Web services.

8. 6/14/20158 Clients invoke individual servers EX: browser, web client EX: Web server EX: 1. File server, 2. Web crawler

9. 6/14/20159 A service provided by multiple servers EX: akamai (data duplication), now amazon aws (zones)

10. 6/14/201510 Web proxy server and caches Proxy servers + cache are used to provide increased Availability and performance. They also play a major role Firewall based security. http://www.interhack.net/pubs/fwfaq/http://www.interhack.net/pubs/fwfaq/

11. 6/14/201511 A distributed application based on peer processes Ex: distributed Whiteboard Application; Music sharing

12. 6/14/201512 Web applets EX: Code streaming; mobile code

13. 6/14/201513 Interaction Models  Within address space (using path as addresses)  Socket based communication: connection- oriented, connection-less Socket is an end-point of communication Lets look at some code + details

14. 6/14/201514 Socket based communication int sockfd; struct sockaddr_in addr; addr.sin_family = AF_INET; addr.sin_addr.s_addr = inet_addr(SERV_HOST_ADDR); addr.sin_port = htons(SERV_TCP_PORT); sockfd = socket(AF_INET, SOCK_STREAM, 0); connect(sockfd, (struct sockaddr *) &addr, sizeof(serv_addr)); do_stuff(stdin, sockfd);

15. 6/14/201515 Classic view of network API  Start with host name (maybe) foo.bar.com

16. 6/14/201516 Classic view of network API  Start with host name  Get an IP address foo.bar.com gethostbyname() 10.5.4.3

17. 6/14/201517 Classic view of network API  Start with host name  Get an IP address  Make a socket (protocol, address) foo.bar.com gethostbyname() 10.5.4.3 sock_id socket();connect();…

18. 6/14/201518 Classic view of network API  Start with host name  Get an IP address  Make a socket (protocol, address)  Send byte stream (TCP) or packets (UDP) foo.bar.com gethostbyname() 10.5.4.3 sock_id socket();connect();… TCP sockUDP sock Network 1,2,3,4,5,6,7,8,9... … Eventually arrive in order May or may not arrive

19. 6/14/201519 Protocol layering  Communications stack consists of a set of services, each providing a service to the layer above, and using services of the layer below Each service has a programming API, just like any software module  Each service has to convey information one or more peers across the network  This information is contained in a header The headers are transmitted in the same order as the layered services

20. 6/14/201520 Protocol layering example Browser process HTTPTCPLink1 IP Link1 IP Link2 Web server process HTTPTCPLink1 IP Physical Link 1Physical Link 2 Router

21. 6/14/201521 HTTP Protocol layering example Browser process TCP Link1 IP Link1 IP Link2 Web server process HTTP TCP Link1 IP Physical Link 1Physical Link 2 Router H Browser wants to request a page. Calls HTTP with the web address (URL). HTTP’s job is to convey the URL to the web server. HTTP learns the IP address of the web server, adds its header, and calls TCP.

22. 6/14/201522 HTTP Protocol layering example Browser process TCP Link1 IP Link1 IP Link2 Web server process HTTP TCP Link1 IP Physical Link 1Physical Link 2 H TCP’s job is to work with server to make sure bytes arrive reliably and in order. TCP adds its header and calls IP. (Before that, TCP establishes a connection with its peer.) T Router

23. 6/14/201523 HTTP Protocol layering example Browser process TCP Link1 IP Link1 IP Link2 Web server process HTTP TCP Link1 IP Physical Link 1Physical Link 2 H IP’s job is to get the packet routed to the peer through zero or more routers. IP determines the next hop from the destination IP address. IP adds its header and calls the link layer (i.e. Ethernet) with the next hop address. T Router I

24. 6/14/201524 HTTP Protocol layering example Browser process TCP Link1 IP Link1 IP Link2 Web server process HTTP TCP Link1 IP Physical Link 1Physical Link 2 H The link’s job is to get the packet to the next physical box (here a router). It adds its header and sends the resulting packet over the “wire”. T Router IL1

25. 6/14/201525 HTTP Protocol layering example Browser process TCP Link1 IP Link1 IP Link2 Web server process HTTP TCP Link1 IP Physical Link 1Physical Link 2 H The router’s link layer receives the packet, strips the link header, and hands the result to the IP forwarding process. T Router I

26. 6/14/201526 HTTP Protocol layering example Browser process TCP Link1 IP Link1 IP Link2 Web server process HTTP TCP Link1 IP Physical Link 1Physical Link 2 H The router’s IP forwarding process looks at the destination IP address, determines what the next hop is, and hands the packet to the appropriate link layer with the appropriate next hop link address. T Router I

27. 6/14/201527 HTTP Protocol layering example Browser process TCP Link1 IP Link1 IP Link2 Web server process HTTP TCP Link1 IP Physical Link 1Physical Link 2 H The packet goes over the link to the web server, after which each layer processes and strips its corresponding header. T Router IL2 HTI HT H

28. 6/14/201528 Basic elements of any protocol header  Demuxing field Indicates which is the next higher layer (or process, or context, etc.)  Length field or header delimiter For the header, optionally for the whole packet  Header format may be text (HTTP, SMTP (email)) or binary (IP, TCP, Ethernet)

29. 6/14/201529 Demuxing fields  Ethernet: Protocol Number Indicates IPv4, IPv6, (old: Appletalk, SNA, Decnet, etc.)  IP: Protocol Number Indicates TCP, UDP, SCTP  TCP and UDP: Port Number Well known ports indicate FTP, SMTP, HTTP, SIP, many others Dynamically negotiated ports indicate specific processes (for these and other protocols)  HTTP: Host field Indicates “virtual web server” within a physical web server

30. 6/14/201530 IP (Internet Protocol)  Three services: Unicast: transmits a packet to a specific host Multicast: transmits a packet to a group of hosts Anycast: transmits a packet to one of a group of hosts (typically nearest)  Destination and source identified by the IP address (32 bits for IPv4, 128 bits for IPv6)  All services are unreliable Packet may be dropped, duplicated, and received in a different order

31. 6/14/201531 IP(v4) address format  In binary, a 32-bit integer  In text, this: “128.52.7.243” Each decimal digit represents 8 bits (0 – 255)  “Private” addresses are not globally unique: Used behind NAT boxes 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16  Multicast addresses start with 1110 as the first 4 bits (Class D address) 224.0.0.0/4  Unicast and anycast addresses come from the same space

32. 6/14/201532 UDP (User Datagram Protocol)  Runs above IP  Same unreliable service as IP Packets can get lost anywhere:  Outgoing buffer at source  Router or link  Incoming buffer at destination  But adds port numbers Used to identify “application layer” protocols or processes  Also a checksum, optional

33. 6/14/201533 TCP (Transmission Control Protocol)  Runs above IP Port number and checksum like UDP  Service is in-order byte stream Application does not absolutely know how the bytes are packaged in packets  Flow control and congestion control  Connection setup and teardown phases  Can be considerable delay between bytes in at source and bytes out at destination Because of timeouts and retransmissions  Works only with unicast (not multicast or anycast)

34. 6/14/201534 UDP vs. TCP  UDP is more real-time Packet is sent or dropped, but is not delayed  UDP has more of a “message” flavor One packet = one message But must add reliability mechanisms over it  TCP is great for transferring a file or a bunch of email, but kind-of frustrating for messaging Interrupts to application don’t conform to message boundaries No “Application Layer Framing”  TCP is vulnerable to DoS (Denial of Service) attacks, because initial packet consumes resources at the receiver

35. Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 4 © Pearson Education 2005 Figure 2.8 Real-time ordering of events

36. Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 4 © Pearson Education 2005 Figure 2.9 Processes and channels

37. Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 4 © Pearson Education 2005 Figure 2.10 Omission and arbitrary failures Class of failureAffectsDescription Fail-stopProcessProcess halts and remains halted. Other processes may detect this state. CrashProcessProcess halts and remains halted. Other processes may not be able to detect this state. OmissionChannelA message inserted in an outgoing message buffer never arrives at the other end’s incoming message buffer. Send-omissionProcessA process completes asend, but the message is not put in its outgoing message buffer. Receive-omissionProcessA message is put in a process’s incoming message buffer, but that process does not receive it. Arbitrary (Byzantine) Process or channel Process/channel exhibits arbitrary behaviour: it may send/transmit arbitrary messages at arbitrary times, commit omissions; a process may stop or take an incorrect step.

38. Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 4 © Pearson Education 2005 Figure 2.11 Timing failures Class of FailureAffectsDescription ClockProcessProcess’s local clock exceeds the bounds on its rate of drift from real time. PerformanceProcessProcess exceeds the bounds on the interval between two steps. PerformanceChannelA message’s transmission takes longer than the stated bound.

39. Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 4 © Pearson Education 2005 Figure 2.12 Objects and principals

40. Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 4 © Pearson Education 2005 Figure 2.13 The enemy Communication channel Copy of m Process p q m The enemy m’

41. Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 4 © Pearson Education 2005 Figure 2.14 Secure channels Principal A Secure channel Process p q Principal B

42. 6/14/201542 Summary  When designing systems or analyzing systems, you want to examine at the high level the architectural model.  Subsequent steps will explore fundamental models such as interaction model, security model, failure model, reliability model etc.