1. System Models

2. Architectural model Structure of the system in terms of components Goals:  reliable, manageable, adaptable, cost-effective system design We will see: What are the components Placement of the components, and Interrelationships between the components Component processes Server process, client process, peer process

3. Software Layers in DS (Software Architecture) The term s/w architecture referred originally to the structuring of s/w as layers or modules in a single computer and more recently in terms of services offered and requested between processes located in the same or different computers. This process- and service-oriented view can be expressed in terms of service layers

4. Software Layers in DS (Software Architecture) Applications, services Computer and network hardware Platform Operating system Middleware Ex. x86/Windows, SPARC/Solaris, PowerPC/MacOS, x86/Linux To mask the heterogeneity & to provide a convenient Programming model

5. Middleware Basics Representation processes or objects interacting with each other to implement communication and resource sharing Function provides building blocks for developing SW components that can interact in a DS An Important goal is to hide the heterogeneity of the underlying platforms from applications Examples Remote method invocation, group communication, replication Earliest middlewares: Sun RPC, ISIS group communication OO middlewares: OMG’s CORBA, MS’s DCOM, Java RMI

6. Middleware basics (contd.) Services for application programs CORBA: naming, security, transaction, persistent storage, event notification Limitations of middlewares Many dist. apps rely entirely on middleware services for communication and data sharing. But some aspects of dependability require support at the application level. Saltzer, Reed and Clarke’s classic paper “End-to-end Arguments in System Design” makes a valuable point about the design of distributed systems.  The paper appeared in ACM TOCS vol. 2 (9), 1984.

7. Middleware To paraphrase their statement: Some communication related functions can be completely and reliably implemented only with the knowledge and help of the application standing at the end points of the communication system. Therefore, providing that function as a feature of the communication system itself is not always sensible. Their argument runs counter to the view that all communication activities can be abstracted away from the programming of applications by the introduction of appropriate middleware layers.

8. Distributed systems Architectures Client-server architectures Distributed services which are called on by clients. Servers that provide services are treated differently from clients that use services Basic model Variations Distributed object architectures No distinction between clients and servers. Any object on the system may provide and use services from other objects Objects and interfaces

9. The Client-Server Model A server is a program that provide a service. It makes some resource available to other programs running somewhere on the network. The resource could be anything: a database, a file system, a printer, a modem, a screen, or a scanner. The server program runs on the machine which resource is attached to, and waits passively until the services are required. Servers are often started up at boot-time, via commands in a start- up script and Servers usually spent most of their time asleep, waiting for work. A client is a program that uses a resource. It may be running on the machine to which the resource is attached, or on a different machine. A client actively makes a connection across the network to the server it requires.

10. The Client-Server Model (cont.) The terms client and server are sometimes used to refer to a machine. We may point out a computer on our network which has a large disk attached and say “That is our file server, and these workstations here are its clients”. We may refer to a machine with a printer attached as a “print server”. The term client and server refer to the relationship between individual programs, not to machines. In general, machines cannot simply be labeled as clients and servers.

11. The Client-Server Model (cont.) One machine might be a server for a piece of the file system, but a client of a remote print server. Example, a program which is a server for a database might itself contact a time server to obtain an accurate timestamp to attach to a new record in the database. In UNIX world, the term daemon is sometimes used to refer to a server. It means that the server is “permanently available”, which implies that it is started at boot-time. Daemon usually provide a “system-related” service, such as: rlogind, telnetd, ftpd, httpd, nfsd,… etc.

12. Client-server architectures The application is modelled as a set of services that are provided by servers and a set of clients that use these services Clients know of servers but servers need not know of clients Server name/IP address and Port number Clients and servers are logical processes Can be in the same machine The mapping of processors to processes is not necessarily 1 : 1

13. Client-Server architecture Server Client invocation result Server invocation result Process: Key: Computer: Servers may in turn be clients Web servers may be clients of File servers, DNS servers

14. A service provided by multiple servers Server Service Client Replicated data partitioned in multiple servers.

15. Web proxy server Involves caching of data improves availability and performance Proxy servers may be used to access remote web servers through a firewall

16. A distributed application based on peer processes Coordination Application code Coordination Application code Coordination Application code Code in the peer process maintains consistency and synchronization No designated clients or servers All play similar roles interacting cooperatively as peers.

17. Variations on the client-server model Several variations can be derived from the consideration of the following factors: The use of mobile code and mobile agents User’s need for low-cost computers with limited h/w resources that are simple to manage The requirement to add and remove mobile devices in a convenient manner

18. Layered application architecture Presentation layer (UI) Concerned with presenting the results of a computation to system users and with collecting user inputs Application processing layer Concerned with providing application specific functionality e.g., in a banking system, banking functions such as open account, close account, etc. Data management layer Concerned with managing the system databases

19. Fat client model More processing is delegated to the client as the application processing is locally executed Most suitable for new Client-Server systems where the capabilities of the client system are known in advance More complex than a thin client model especially for management. New versions of the application have to be installed on all clients

20. Example of a Three-tiered System The general organization of an Internet search engine into three different layers 1-28

21. Multi-tiered Architectures Alternative client-server organizations (a) – (e). 1-29

22. Other Variations of client-server model: Mobile Code a) client request results in the downloading of applet code Web server Client Web server Applet Applet code Client b) client interacts with the applet Java applets Push model: initiated by the server Pull model: initiated by the client

23. Mobile Code It can give good interactive response since it does not suffer from the delays or variability of b/w associated with network communication. Potential security threat to the local resources --- give applets limited access to local resources.

24. Mobile agent Mobile agents A running program that travels from one machine to other in a network carrying out task on someone’s behalf eventually returning with the result.  e.g. install and maintain s/w on the computers within an organization or compare the prices of products from a number of vendors by visiting the site of each vendor and performing a series of database operations. A potential security threat The environment receiving a mobile agent should decide on which of the local resources it should be allowed to use, based on the identity of the user on whose behalf the agent is acting

25. Interfaces and Objects Distributed processes can also be developed by using objected oriented languages (C++/Java) Many objects can be encapsulated in server or peer processes, and reference to them are passed to other processes so that their methods can be accessed by remote invocation. Adopted by --- CORBA Java RMI New services and new types of object can be instantiated and immediately be made available for invocation – dynamic.

26. Fundamental models A system model defines  the entities  their interactions  characteristics that affect their behavior purposes  explicitly states all relevant assumptions  generalize what is possible or not based on the assumptions We’ll study  Interaction model  Failure model  Security model

27. Fundamental models Concerned with the properties that are common in all of the architectural models. No global time in a DS – clocks on different computers do not necessarily give the same time.

28. Fundamental models All communication between processes is achieved by means of messages – message communication over a network can be affected by delays, can suffer from a variety of failures and is vulnerable to attacks. These issues are addressed by three models.

29. Interaction model, Failure model & Security model Interaction model deals with the performance and with the difficulty of setting time limits in a Distributed System.

30. Interaction model, Failure model & Security model Failure model attempts to give a precise specification of the faults that can be exhibited by a process and communication channels. It defines reliable communication and correct processes.

31. Interaction model, Failure model & Security model Security models discusses the possible threats to processes and communication channels. Introduces the concept of a secure channel, which is secure against those threats.

32. Interaction model Issues related to the interactions between processes What are the issues? process p q Communication channel send Outgoing message bufferIncoming message buffer receivem

33. Interaction model Significant factors affecting interacting processes in a distributed system Communication performance is often a limiting characteristics It is impossible to maintain a single global notion of time

34. Interaction model Performance of Communication channel Latency: the delay between the sending of a message by one process and its receipt by another is referred to as latency that includes  propagation delays – time taken for the first of a string of bits transmitted through a network to reach its destination  network delays – delay in accessing the network  OS delays – time taken by the OS communication services at both the sending and receiving processes Bandwidth  The capacity of the communication channel Jitter  Variation in time taken to deliver a series of messages.  Relevant to multimedia data -- Audio-video

35. Interaction model Clocks and timing Absence of global clock, clock drift rate Two important variants of the Interaction Model It is hard to set time limits on the time taken for processor execution, message delivery or clock drift. Two opposing extreme positions provide a pair of simple models The first has a strong assumption of time and the second makes no assumptions about time Synchronous DS Asynchronous DS

36. Synchronous and asynchronous DS Synchronous Processing time (time to execute each step of a process) has a known lower and upper bound Msg. Transmission delay is within a known bound Local clock drift rates are also within a known bound Examples: Multiprocessor systems Asynchronous Processing time doesn’t have any bound Msg. Transmission delay doesn’t have any bound Local clock drift rates don’t have any bound Examples: Internet, wireless networks, datacenters, most real systems

37. Synchronous and asynchronous DS Synchronous Possible to suggest likely upper & lower bounds but difficult to arrive at a realistic values and to provide guarantee for the chosen values Possible to use timeouts Unless the values of the bounds are guaranteed, any design based on those will not be reliable Modeling an algorithm as a synchronous system may be useful for giving some idea of how it will behave in a real distribute system

38. Synchronous and asynchronous DS Asynchronous Many DS (e.g. Internet) are very useful w/o being able to qualify as synchronous system Actual DS are very often asynchronous There are many design problems that cannot be solved for an asynchronous system that can be solved when some aspects of time are used. Any solution that is valid for asynchronous DS is also valid for synchronous DS

39. Real-time ordering of events send receive send receive m 1 m 2 2 1 3 4 X Y Z Physical time A m 3 receive send receive t 1 t 2 t 3 m 2 m 1 User A: X sends a message with the subject “Meeting” Y and Z reply with the subject “Re: Meeting” From Subject

40. Failure model Types of failures Omission failure  process  communication channel Arbitrary failure Timing failure process p q Communication channel send Outgoing message bufferIncoming message buffer receive m

41.  Process omission failure  Crash-stop (fail-stop) – a process halts and does not execute any further operations  Crash-recovery – a process halts, but then recovers (reboots) after a while  Special case of crash-stop model (use a new identifier on recovery)  We will focus on Crash-stop failures  They are easy to detect in synchronous systems  Not so easy in asynchronous systems Failure Types

42.  Communication omission failures  Send-omission: loss of messages between the sending process and the outgoing message buffer (both inclusive)  What might cause this?  Channel omission: loss of message in the communication channel  What might cause this?  Receive-omission: loss of messages between the incoming message buffer and the receiving process (both inclusive)  What might cause this? Failure Types

43.  Arbitrary failures  Arbitrary process failure: arbitrarily omits intended processing steps or takes unintended processing steps.  Arbitrary channel failures: messages may be corrupted, duplicated, delivered out of order, incur extremely large delays; or non-existent messages may be delivered.  Above two are Byzantine failures, e.g., due to hackers, man-in-the- middle attacks, viruses, worms, etc., and even bugs in the code  A variety of Byzantine fault-tolerant protocols have been designed in literature! Failure Types

44. Omission and Arbitrary Failures Class of failureAffectsDescription Fail-stop or Crash-stop ProcessProcess halts and remains halted. Other processes may 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.

45. Masking & reliability Masking failures: Some services can mask a failure, e.g., checksums are used to mask corrupted messages – effectively converting an arbitrary failure into an omission failure, omission failures can be masked by retransmission Reliable communication is defined in terms of : - Validity: a message eventually reaches the destination - Integrity: the message received is identical to the message sent

46. Security model The security of a DS can be achieved by securing the processes and the channels used for their interactions and by protecting the objects that they encapsulate against unauthorized access Access rights – specify who is allowed to perform the operations of an object Principal – associated with each invocation and each result the authority on which it is issued. A principal may be a user or a process

47. Securing Processes and their Interactions Processes interact by sending messages Due to the openness of the underlying networks and the communication services, the messages are vulnerable to attacks The Enemy To model security threats we postulate an enemy or an adversary who can pose security threats Threats assessment is an important aspect of security model

48. Security threats Communication channel Copy of m Process p q m The enemy m’ The enemy (intruder) 1. Threats to the processes 2. Threats to the servers 3. Threats to the communication channel

49. Secure channel Encryption and authentication are used to build secure channels as a service layer on top of existing communication services. Has the following props. Each process knows reliably the identity of the principal on whose behalf the other process is executing Ensures the privacy and integrity of the data transmitted across it Each message includes a physical or logical timestamp to prevent messages from being replayed or reordered Other forms of threats: 1. Denial of service attacks 2. Threats associated with the mobile codes