Eng. Mohammed Timraz Electronics & Communication Engineer

1. University of Palestine Faculty of Engineering and Urban planning Software Engineering Department Distributed SystemsESGD4221 Chapter 2 Eng. Mohammed Timraz Electronics & Communication Engineer Sunday, 13th February 2011

2. Fundamental Models • What is a model? • It provides only essential elements to consider for reasoning and understanding the system behavior. • Addresses the following questions: • What are the main entities in the system? • How do they interact? • What are the characteristic that affect their individual and collective behavior? • We use a model for… • Making relevant assumptions about the system modeled. • Making generalizations concerning what is possible or not possible. These generalization assume the form of algorithms or properties that are guaranteed (i.e. dependent on logical analysis or mathematical proof) Lecture 2

3. Fundamental Models • Aspect to consider for DS • Interaction • DS are constituted by interacting processes • Interaction can be: • Communication (message passing) • Coordination (information flow) • Failure • Faults occurs usually in distributed environment • A classification of them helps understanding the weakness of the systems and the possible counter-actions. • Security • Modularity and openness expose the system to threats • It is necessary to classify the attacks and devises potential resistance measures. Lecture 2

4. Fundamental Models • Interaction Model • Facts (problems): • Communication takes place with delays (often of considerable duration) • Delays and the absence of global time limit the accuracy with which we can coordinate processes. • What are the element of interest? • Performance Communication Channels • Computer Clocks and Timing Events • Synchronous vs Asynchronous models • Event Ordering Lecture 2

5. Fundamental Models • Interaction Model • Performance Communication Channels: There are some challenges for Appling DS system on the network. • Various implementations, platforms, applications, methods, no of hobs and designers. In general the following elements are important to take care: • Latency • Time taken for transmitting the first bit of a string of bytes • Delay in accessing the network (varies according to load) • Time taken by communication service and OS for processing • Bandwidth • Total amount of information transmissible in the unit of time • Jitter • Variation in the time taken to deliver a message Lecture 2

6. Fundamental Models • Interaction Model • Computer Clocks and Timing Events • Timing faults can occur in synchronous distributed systems, where time limits are set to process execution, communications, and clock drifts. • A timing fault occurs if any of this time limits is exceeded. How? Lecture 2

7. Fundamental Models • Interaction Model • Computer Clocks and Timing Events • Each computer has its own internal clock. • Two processes running on different computers will end up to have a different clock (and timestamps for events) • Computer clocks drift from the perfect time at different rates. • Without corrections such clocks will vary considerably over a long period of time. • Possible solutions: • GPS (ok for open spaces) • Timing protocols (variable to message delays) Lecture 2

8. Fundamental Models • Interaction Model • Synchronous vs. Asynchronous Models • Synchronous Systems (Assumptions) • Process step execution time has known lower and upper bounds. • Each message transmission over a channel has a bounded time. • Local clock drift rate from real time has a known bound. • It is difficult and costly to implement synchronous distributed systems. • Asynchronous Systems • None of the previous assumptions are valid. • Heterogeneity in all of the three aspects. • Observations: • It is possible to suggest likely upper and lower bound. • It is very difficult to provide accurate realistic values. • The use of synchronous system models is not realistic but might be helpful in designing initial versions of the system. Lecture 2

9. Fundamental Models • Interaction Model • Event Ordering • Sequence of events is important • The execution of a system can be described in terms of the sequence of events that occur in it • Clocks cannot be synchronized perfectly across a distributed system. • It is possible to order events in the absence of global clock? Lecture 2

10. Fundamental Models Inbox of A: … 23 Z Re: Meeting 24 X Meeting 25 Y Re: Meeting …. Can A reconstruct the proper sequence? • Interaction Model • Event Ordering – The meeting problem send send send receive receive m1 X receive receive m2 Y receive receive m3 Z receive receive receive A t3 t2 t1 Lecture 2

11. Fundamental Models • Interaction Model • Event Ordering • Logical Time (Lamport 1978) can help reconstruct the sequence ordering of events in absence of global clock. • A number is assigned to each event. • This number represents the logical order of the event in the sequence. Lecture 2

12. Fundamental Models • Failure Model • What is failure? • Process and communication may depart from what is the expected behavior. • What is a failure model? • Defines the ways in which failure may occur in order to provide understanding of the effects it can cause. • Observations • Different kinds of failures can be addressed differently • Different kinds of failures denote different (major or minor) problems • Classification of failures is then important. Lecture 2

13. Fundamental Models • Failure Model • Taxonomy of Failures • Applies to Processes and Communication • Categorization: • Omission Failures • Arbitrary or Byzantine Failures • Timing Failures Lecture 2

14. Fundamental Models • Failure Model • Omission Failures • Characterization • A process or a communication channel fails in performing what it is supposed to do. • Possible Types: • Process omission Failures • Process crashes (fail-stop if can be detected, complete crash or abnormal residual behavior?) • Communication channel Omission Failures • Dropping messages (channel omission) • Send-omission failures • Receive-omission failures Lecture 2

15. Fundamental Models • Failure Model • Arbitrary Failures or Byzantine Failures • Characterization • Worst possible failure semantics. • Any type of any error can occur. • Types: • Process arbitrary failures • Insertion of invalid data. • Invalid execution paths. • Channel arbitrary failures • Message content corruption • Unintended messages delivered • Duplication Difficult to detect by simply checking whether the process responds to the invocation.. Easily detectable by the communication software. Lecture 2

16. Fundamental Models • Failure Model • Timing Failures • Synchronous Systems • An operation executes beyond its time limits. • Asynchronous Systems • Difficult to characterize, since there are no bounds on the time. • Solutions: • Real-time operating systems Lecture 2

17. Fundamental Models • Failover Model • Masking Failures • It is possible to construct reliable services from components that exhibit failures. • Failure detection is important to identify the wrong behavior and then provide a counter-measure • Data replication • Checksums and error correction • Message retransmissions • A failure can be … • … completely masked • … turned into an acceptable failure Lecture 2

18. Fundamental Models • Security Model • The security of a distributed system can be achieved by • Securing the processes composing the system. • Securing the channels they use to communicate. • Protecting the objects they encapsulate by unauthorized access. Lecture 2

19. Fundamental Models • Security Model • Protecting objects • Avoiding unauthorized access • Identifying • who is accessing what • what permission does he/she have on the object • Each service request operating on sensitive objects has to occur under a specific authority • Concept of Security Principal • Concept of Access Rights. Lecture 2

20. Fundamental Models • Security Model • Protecting objects • Example Request + Credentials Sensitive Object User Principal + Access Rights Internet <Untrusted Zone> Security Service Server Lecture 2

21. Fundamental Models • Security Model • Securing Processes and their Interactions • Process interact through • Message passing • Publicly available interfaces • Assumptions • The communication channel is untrusted • Potential misuses of the services exposed by the process • Observations • How can we protect processes from the enemy? • What are the potential threats? Lecture 2

22. Fundamental Models • Security Model • Identifying the Enemy • Malicious entity (user or program) capable of • sending message through the network to any process • reading or copying any message between a pair of processes • impersonating one end point of the communication m1 m1 m1’ Lecture 2

23. Architectural Models • Security Model • Classification of Threats • Threats to Processes • Impersonation (generation, alteration of network packets) • Threats to both servers (requests) and clients (responses) • Threats to Communication Channels • Injection, alteration of messages • Message copy • Threats for privacy and integrity • Countermeasure: secure channels • Denial of Service: generation of false request • Mobile Code: untrusted, unknown, potentially harmful Lecture 2

24. Fundamental Models • Security Model • Countermeasures • Cryptography and shared secrets • Processes shared a secret helping them communicating safely • The shared secret can be used as key to encrypt messages over an unsecure channel • Cryptography: science of keeping message secures • Encryption: process of altering a message so that its content cannot be read by unintended receivers. • Authentication • The knowledge of the secret ensures the identity of both endpoints • The secret can be used to identify the sender Lecture 2

25. Fundamental Models • Security Model • Countermeasures • Secure Channels • Encryption and Authentication can be used to build a secure channel. • A secure channel can be considered as a service layer on top of existing communication services. • It is a communication channel that connects a pair of processes, each of which acts on behalf of a principal. • Channel properties. • Each end point knows who resides on the other end point. • The channel ensures privacy and integrity of messages. • Each message includes a physical and logical time-stamp to prevent copies. Lecture 2

26. Fundamental Models • Security Model • Use of Security Models • The techniques discussed in this section constitute the fundamental blocks to build a security infrastructure. • Additional issues arises in a real system • Performance vs Security: security measure introduce processing costs. • Other threats beyond the ones listed can be considered • Human factor • Geo-location • A careful analysis of all the aspects of a DS (hardware, software, network, and human) allows to build a threat model. Lecture 2

27. Fundamental Models • Security Model • Use of Security Models • The threat model lists all the potential attacks that the systems might be exposed to. • Security costs have to be balanced against these attacks • Bottom line: • “how much your enemy is willing to pay to break your security?” Lecture 2

28. Summary • What do we have learnt? • Architectural Models • An architectural model of a distributed system is concerned with the placement of its parts and the relationship between them. • It defines the way in which the components of systems interact with one another and the way in which they are mapped onto an underlying network of computers. • Design Requirements • Focus on performance, quality of service, dependability and security • Fundamental models • What is a model and its characteristics • 3 Fundamental models • Interaction model • Communication model • Security model Lecture 2

29. Remote procedure call • A remote procedure call makes a call to a remote service look like a local call • RPC makes transparent whether server is local or remote • RPC allows applications to become distributed transparently • RPC makes architecture of remote machine transparent Lecture 2

30. RPC Description • RPC is a widely used communications process for building distributed applications. • An RPC is really a process invocation, not a procedure call. An invoked program runs in another domain. • RPCs hide the intricacies of the network by using the procedure call mechanism familiar to programmers. • They make life easy for programmers, but hard for Network OS designers. Lecture 2

31. RPC vs. Local Procedure • 4 properties of distributed computing that make achieving transparency difficult: • Partial failures • Concurrency • Latency • Memory access Lecture 2

32. Partial failures • In local computing: • if machine fails, application fails • In distributed computing: • if a machine fails, part of application fails • one cannot tell the difference between a machine failure and network failure • How to make partial failures transparent to client? Lecture 2

33. Network OS Issues • How are server functions located and started? • How are parameters defined and passed between client and server? Better NOS’s usually offer an Interface Definition Language (IDL) with an IDL compiler. • How are failures handled? • How does RPC handle security? • How does client find its server? • How is data translated for different systems? (Big-endian vs little-endian, ASCII vs. others, etc.) Lecture 2

34. Synchronous RPC Call Client Application RPC Call Invoke Service Call Service Service Executes Client Computer Request Completed Return Answer Program Continues Return Reply Server Computer Lecture 2

35. Lecture 2

36. RPC • Remote Procedure Call allows a client to execute procedures on other computers. • RPC forms the foundation for most of the distributed utilities used today, like NFS and NIS. • RPC simplifies the task of writing client/server programs. Lecture 2

37. Differences between RPC and Local Procedure Calls • Error handling: RPC programs must handle remote errors • Side Effects and Global Variables: Server does not access client address space, so hidden arguments cannot be passed. • Performance: RPC is usually much slower. • Authentication: RPC may operate over an unsecured network, so verification may need to be done by developer. Lecture 2

38. Client Server Client Procedure Called Procedure arguments results Client Stub Server Stub Network transport Network Transport Network RPC process Lecture 2

39. Developing an RPC Application • Specify the protocol for client/server communication • Develop the client and server programs Lecture 2

40. Developing the Application Protocol • Define the interface between the client and server. • identify the names of service procedures and the data types of parameters and return arguments. • Use the protocol compiler to generate the client and server stubs. Lecture 2

41. Different Types of Protocol Compilers for RPC • Netwise RPCTOOL • Sun Open Network Computing RPCGEN • NIDL OFS/NCS • Xerox Courier XNS SPP • Apollo Network Computing Architecture NCA Lecture 2

42. RPCL Protocol Definition File • The RPC Language definition file uses a .x extension • It contains the preprocessor directives, constant and structure definitions, program definitions and. • The protocol definition file is compiled with the rpcgen command to create a client stub, a server stub, and a header file for use in the client and server application programs. Lecture 2

43. ONC RPC Data Types • constant • enumeration • structure • union • typedef • program Lecture 2

44. External Data Representation • What’s XDR? • XDR is independent of any particular platform • Why XDR? Different internal representation of data: • Data size • Opaque (byte stream) • Typed (customized structure) • Byte order (big-endian or little-endian) Lecture 2

45. Some Basic XDR data elements • Integers • 4bytes, (0,1,2,3, big endian), 2’s compliment • Variable-length opaque data • Length n*(4bytes), data ended by NULL padded • Strings • Length n*(4bytes), data ended by NULL padded • Arrays • Size n*(4bytes), same type of data • Structures • Natural order Lecture 2

46. Example XDR Encoding Lecture 2

47. ONC RPC Program Numbers • 0x00000000 to 0x1FFFFFFF Defined by Sun • 0x20000000 to 0x3FFFFFFF User-Defined • 0x40000000 to 0x5FFFFFFF Transient • 0x60000000 to 0xFFFFFFFF Reserved • Sun Microsystems administers the first range, identical for all users, for internal use such as the Portmapper. The second group is assigned by application developers for their programs. The third group is reserved for programs that generate program numbers dynamically. Lecture 2

48. RPC Port Mapper • ONC Programs do not bind to specific protocol ports like several other technologies. Instead, they use a Portmapper, which dynamically allocates an arbitrary unused protocol port for a connection. An application does need to know what port to use to contact the Portmapper, but that is usually standardized in a company. Lecture 2

49. Compiling the Protocol Definition rpcgen file.x client stub: file_clnt.c server stub: file_svc.c XDR filters: file_xdr.c header file: file.h Lecture 2

50. RPC Specification RPC Compiler Shared Filters and Header Files Client Stub Server Skeleton Compile and Link Compile and Link RPC and Data Representation Libraries Client Functions Server Functions Server Executable Client Executable Lecture 2