Presentation is loading. Please wait.

Presentation is loading. Please wait.

System Models Chapter 2: Coulouris +

Similar presentations


Presentation on theme: "System Models Chapter 2: Coulouris +"— Presentation transcript:

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

2 Distributed system models
“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.” 2/15/20192/15/2019

3 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. 2/15/20192/15/2019

4 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. 2/15/20192/15/2019

5 Software and hardware service layers in distributed systems
2/15/20192/15/2019

6 Project 1 System Model 7

7 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: Many web frameworks; the cloud enabled by advances in virtualization 2/15/20192/15/2019

8 Clients invoke individual servers
EX: 1. File server, 2. Web crawler EX: Web server EX: browser, web client 2/15/20192/15/2019

9 A service provided by multiple servers
EX: akamai (data duplication), amazon aws (zones) 2/15/20192/15/2019

10 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. 2/15/20192/15/2019

11 A distributed application based on peer processes
Examples: Bit torrent based sharing; IPFS: Interplanetary file system 2/15/20192/15/2019

12 Case Study from Chapter 1: World wide web (www)
The world wide web (Tim Berner’s Lee: reading material for this week) web/ world-changed-forever/ Web (web 1.0) was world wide web: a killer app for the Internet Web Semantic was well received at the beginning but fluttered off Web 3.0 – What web3.0 define it. 2/15/20192/15/2019

13 Origins of WWW Began as a application for document exchange among a community of physicists connected by the Internet Web is an open system: It can be implemented in new ways without disturbing its existing functionality. Example: There are many types of browsers implemented on different platforms and operating systems Web is also open with respect to types of resources that can be published and shared on it. Any media can be shared as long as you helper/plugin to handle that format of media. 2/15/20192/15/2019

14 2/15/20192/15/2019

15 Main Technical Standards
HTML : Hypertext Markup Language for specifying the contents and structure of contents Uniform Resource Locator (URL) also known as URI (Uniform Resource Identification) that provide uniform identification for resource sin the web space: Scheme: scheme-specific identifier. Example: ftp:// A Client-server system architecture with standard rules for interaction (HTTP) in which browsers and other clients fetch documents and other resources from web servers. Here is a question for you: Lets discuss this? How have these standards evolved since their beginnings? I want some good answers. 2/15/20192/15/2019

16 Web 2.0 HTML5 that include XHTML, well-formed, meaningful tags and interoperability through APIs. HTTP did NOT come with security built-in, HTTP became HTTPS. The interacting parties agree to minimally encrypt the message and maintain a secure channel between them so that a middle person cannot access and misuse transactions and data. and an important abstraction for the webpage called DOM or document object model (DOM) What is next? What is in web3.0? Reading: Read: Chapter 1 WWW case study: pages: 26-33 2/15/20192/15/2019

17 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 2/15/20192/15/2019

18 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); 2/15/20192/15/2019

19 Classic view of network API
Start with host name (maybe) foo.bar.com 2/15/20192/15/2019

20 Classic view of network API
Start with host name Get an IP address foo.bar.com gethostbyname() 2/15/20192/15/2019

21 Classic view of network API
Start with host name Get an IP address Make a socket (protocol, address) foo.bar.com gethostbyname() socket();connect();… sock_id 2/15/20192/15/2019

22 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() socket();connect();… sock_id 1,2,3,4,5,6,7,8, TCP sock UDP sock Network Eventually arrive in order May or may not arrive 2/15/20192/15/2019

23 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 2/15/20192/15/2019

24 Protocol layering example
Browser process Web server process HTTP HTTP TCP TCP Router IP IP IP Link1 Link1 Link2 Link1 Physical Link 1 Physical Link 2 2/15/20192/15/2019

25 Protocol layering example
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. Browser process Web server process HTTP HTTP H TCP TCP Router IP IP IP Link1 Link1 Link2 Link1 Physical Link 1 Physical Link 2 2/15/20192/15/2019

26 Protocol layering example
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.) Browser process Web server process HTTP HTTP TCP TCP Router H T IP IP IP Link1 Link1 Link2 Link1 Physical Link 1 Physical Link 2 2/15/20192/15/2019

27 Protocol layering example
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. Browser process Web server process HTTP HTTP TCP TCP Router IP IP IP H T I Link1 Link1 Link2 Link1 Physical Link 1 Physical Link 2 2/15/20192/15/2019

28 Protocol layering example
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”. Browser process Web server process HTTP HTTP TCP TCP Router IP IP IP Link1 Link1 Link2 Link1 Physical Link 1 Physical Link 2 H T I L1 2/15/20192/15/2019

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

30 Protocol layering example
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. Browser process Web server process HTTP HTTP TCP TCP Router IP IP IP H T I Link1 Link1 Link2 Link1 Physical Link 1 Physical Link 2 2/15/20192/15/2019

31 Protocol layering example
The packet goes over the link to the web server, after which each layer processes and strips its corresponding header. Browser process Web server process HTTP HTTP H TCP TCP Router H T IP IP IP H T I Link1 Link1 Link2 Link1 Physical Link 1 Physical Link 2 H T I 2/15/20192/15/2019 L2

32 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 ( )) or binary (IP, TCP, Ethernet) 2/15/20192/15/2019

33 Demuxing fields Ethernet: Protocol Number IP: 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 2/15/20192/15/2019

34 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 2/15/20192/15/2019

35 IP(v4) address format In binary, a 32-bit integer
In text, this: “ ” Each decimal digit represents 8 bits (0 – 255) “Private” addresses are not globally unique: Used behind NAT boxes /8, /12, /16 Multicast addresses start with 1110 as the first 4 bits (Class D address) /4 Unicast and anycast addresses come from the same space 2/15/20192/15/2019

36 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 2/15/20192/15/2019

37 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) 2/15/20192/15/2019

38 UDP vs. TCP UDP is more real-time UDP has more of a “message” flavor
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 , 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 2/15/20192/15/2019

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

40 Figure 2.14 Processes and channels
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn © Pearson Education 2005

41 Figure 2.15 Omission and arbitrary failures
Class of failure Affects Description Fail-stop Process Process halts and remains halted. Other processes may detect this state. Crash not be able to detect this state. Omission Channel A message inserted in an outgoing message buffer never arrives at the other end’s incoming message buffer. Send-omission A process completes a send, but the message is not put in its outgoing message buffer. Receive-omission A 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. Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn © Pearson Education 2005

42 Figure 2.16 Timing failures
Class of Failure Affects Description Clock Process Process’s local clock exceeds the bounds on its rate of drift from real time. Performance Process exceeds the bounds on the interval between two steps. Channel A message’s transmission takes longer than the stated bound. Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn © Pearson Education 2005

43 Figure 2.17 Objects and principals
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn © Pearson Education 2005

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

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

46 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. 2/15/20192/15/2019


Download ppt "System Models Chapter 2: Coulouris +"

Similar presentations


Ads by Google