1 / 74

Communication

Communication. TANENBAUM-Chapter 2. Layered Protocols (1). 2-1. Layers, interfaces, and protocols in the OSI model. Layered Protocols (2). 2-2. A typical message as it appears on the network. Layered Protocols (3). Connection-oriented Connectionless Lower layer protocols

michaelaj
Télécharger la présentation

Communication

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Communication TANENBAUM-Chapter 2

  2. Layered Protocols (1) 2-1 • Layers, interfaces, and protocols in the OSI model.

  3. Layered Protocols (2) 2-2 • A typical message as it appears on the network.

  4. Layered Protocols (3) • Connection-oriented • Connectionless • Lower layer protocols • Physical Layer: • standardization of electrical, mechanical and signaling interfaces, • It does not handle errors • e.g. RS-232 is standard for physical layer serial communication… Manchester encoding in LAN is another… • Data Link Layer: can detect and correct certain errors in bit strings. • It groups bits into so called frames and adds checksum fields to detect errors • Sequencing is used to identify the frames for error handling

  5. Data Link Layer 2-3 • Discussion between a receiver and a sender in the data link layer.

  6. Network Layer • On LAN: no need for locating the receiver, as it is on the same LAN as the sender, so no routing is required • On wide area network finding the destination is an important task • IP protocol is used for finding the route to the destination; it is part of TCP/IP suit • It is a connectionless protocol • Connection oriented protocols at this level have also gained important ground! ATM networks use virtual circuits..

  7. Transport Protocols (1) • Transport layer is an end-to-end protocol, contrary to the lower layers of protocol • It is a connection-oriented reliable protocol • Transport layer should guarantee the delivery of the message provided by the application. • Applications use the interface provided by the transport layer protocol to access the network… • TCP/IP suit has TCP as connection oriented reliable protocol • TCP/IP suit also provide UDP as the transport level unreliable connectionless protocol

  8. Transport Protocols (2) • Transport protocols, in general can be tuned to the applications • Client-server applications often use transport protocols • TCP is more common than UDP in TCP/IP protocol suit, for this purpose • TCP for transactions can be more efficient as in the next figure

  9. Client-Server TCP 2-4 • Normal operation of TCP. • Transactional TCP.

  10. Higher-Level protocols • IN practice two of the higher layers are not used much… • Session layer does not functionally worth the overhead; • Presentation layer is concerned with meaning associated to the data: e.g., decryption/ encryption • Application protocols can integrate session as well as presentation functionality…

  11. Application Protocols • It includes standard common applications such as ftp, email, terminal emulation, Internet FTP, HTTP • Middleware protocols are use to provide various middleware services that do not fit in transport layer. • Examples: authentication and authorization protocols, distributed transaction commit protocols, distributed locking protocol, remote procedure calls (RPC), remote object invocation, message queuing services, continuous media streams • RPC stands out both historically and in commonality…

  12. Middleware Protocols 2-5 • An adapted reference model for networked communication.

  13. Conventional Procedure Call Read(fd,buf,nbytes) • Parameter passing in a local procedure call: the stack before the call to read • The stack while the called procedure is active

  14. Client and Server Stubs • Principle of RPC between a client and server program.

  15. Steps of a Remote Procedure Call • Client procedure calls client stub in normal way • Client stub builds message, calls local OS • Client's OS sends message to remote OS • Remote OS gives message to server stub • Server stub unpacks parameters, calls server • Server does work, returns result to the stub • Server stub packs it in message, calls local OS • Server's OS sends message to client's OS • Client's OS gives message to client stub • Stub unpacks result, returns to client

  16. Passing Value Parameters (1) 2-8 • Steps involved in doing remote computation through RPC; a shadow remote procedure call stub is put ın the client’s library to make the remote procedure call transparent. At server site server stub is required.

  17. Passing Value Parameters (2) • Marshalling is required between two end machines: e.g. • Pentium uses Little Ending, Sun uses Big Ending • Original message on the Pentium • The message after receipt on the SPARC • The message after being inverted. The little numbers in boxes indicate the address of each byte. The integer 5 is marshaled correctly but the string is incorrectly inverted…

  18. Parameter Specification and Stub Generation • A n RPC call with different type parameters • The corresponding message with special format (IEEE #754).

  19. Interface Definition • Interfaces can be defined using an Interface Definition Language (IDL) • The written the coded interface can then be translated into client stub at the client side and server stub at the server side. • Once the stub are ready, the transmission with the remote counterpart can be achieved the available protocol, eg. TCP/IP

  20. Extended RPC models: Doors • Used when both client and server are in the same address space. Few additional system calls are used to implement this: create, fattach, open, door_call, door_return,

  21. Asynchronous RPC (1) 2-12 • The interconnection between client and server in a traditional RPC: block client until response is received. • The interaction using asynchronous RPC: block client until request received response is received.

  22. Asynchronous RPC (2) 2-13 • A client and server interacting through two asynchronous RPCs: client is interrupted by the server

  23. Distributed Computing Environment(DCE: RPC) • Services: • Distributed file service • Directory service • Security service • Distributed time service • Goal: to provide transparency in all above services, including binding, communication, data type conversion, and language differences… • The DCE RPC includes a number of components including languages, libraries, daemons, and utility programs

  24. Writing a Client and a Server(1) 2-14 • The steps in writing a client and a server in DCE RPC. Uuidgen-Unique interface identifier, never generated again by Uuidgen. Uniqueness is guaranteed by encoding location and the time of the day into 128 bit binary number. Client and server can not share the global variables…

  25. Writing a Client and a Server(2) • UUIDGEN generates a unique user identifier and an IDL file with that identifier • The identifier is 128-bit binary number, so that it can never be reused • Interface Definition Language (IDL) file is than allowed to be updated compiled to produce the stubs and the header file • Server and client codes are then written and compiled with corresponding stub and the header file to be linked with the DCE RPC library, to produce the binaries to be run • DCE daemon maintains a table for server end points • A directory server maintains the address of the registered servers with their network addresses.

  26. Binding a Client to a Server 2-15 • Client-to-server binding in DCE. • RPC performs operation with “at most once” prinsiple.THIS MEANS RPC CALLS ARE NOT REPEATED BY THE CLIENTS, EVEN IN CASE OF SERVER FAILURES… this is done to avoid multiple requests…

  27. Remote Object Invocatıon (1) • Expansion of idea of RPC to method invocations on remote objects to enhance distributed transparency • This desire is fueled by the concept of the object, in which its internals can be hidden from the outside world by means of well-defined interfaces

  28. Remote Object Invocatıon (2) • Principles of RPC can also be applied to objects • Distribution aspects can be hidden behind the object’ interface CORBA is an industry defined standard for distributed application development DCOM is Microsoft counterpart for CORBA, as middleware for the Windows domain of operating systems • Separation between the interface and the object implementation can be explored for distributed applications, so that interface is in one machine while object is on another. • In object based RPC model, counter parts of client stub in conventional RPC is proxy, that of the server is the skeleton to conduct marshalling and un-marshalling, to each others. Note that the object state may or may not be distributed, but if distributed it can be transparent to the application.

  29. Remote Object Invocatıon (3): Distributed Objects 2-16 • Common organization of a remote object with client-side proxy, ie. interface on the client machine, server on another….

  30. Remote Object Invocatıon (4): Compile time vs Runtime Objects • The objects implemented using Java and C++ are compile time objects, in which the objects are instances of classes. • Compile time objects depend on the particular programming language used. It is easier to built such applications. • Alternatively, the distributed objects can be created during the runtime and made programming language independent, wrapped by a rapper so that the implementation appears as an object. • Adapters should allow an interface to be converted to what the clients expect.

  31. Remote Object Invocation (5): Object Persistence • Persistent object continues to exists even if the server cease to exist. • A persistent object is saved on the secondary storage by a server and retrieved into the scope of the server, whenever needed. • Transient object cease to exist as soon as the servers do so.

  32. Remote Object Invocatıon (6): Object binding • In distributed objects case, a system wide object reference is common. • Object references can even be passes as parameters in method invocations. • A process must first be bound to an object’s reference before invoking any of its methods, perhaps using a proxy. • The binding can be implicit, just like local reference; or it can be explicit in which it needs to find the object before being bind.

  33. Remote Object Invocatıon (7): Implementation of Object References • Object reference depicts the address of the server object which include the machine it resides, the server identification, and the object identification • The transparency can be improved by using server location servers that keep track of the machine where the servers are and their endpoints on those machines • As a further transparency, an object reference may have additional information, such as the protocols implemented by the object • This may lead to use of an implementation handle which dynamically loads the object specific proxy to provide binding: So clients need not to worry about the details of the implementation.

  34. Remote Object Invocatıon (8): Binding a Client to an Object Distr_object* obj_ref; //Declare a systemwide object referenceobj_ref = …; // Initialize the reference to a distributed objectobj_ref-> do_something(); // Implicitly bind and invoke a method (a) Distr_object obj_ref; //Declare a systemwide object referenceLocal_object* obj_ptr; //Declare a pointer to local objectsobj_ref = …; //Initialize the reference to a distributed objectobj_ptr = bind(obj_ref); //Explicitly bind and obtain a pointer to the local proxyobj_ptr -> do_something(); //Invoke a method on the local proxy (b) • An example with implicit binding using only global references • An example with explicit binding using global and local references

  35. Remote Object Invocation (9): Static vs Dynamic RMI • Static remote method invocation implies imbedding the object interfaces into the program, thus requires recompilation if the object interface changes. • In dynamic invocation, the method to invoke is selected run time. • Example for static rmi: fobject.append (int) • Example for dynamic rmi: invoke(fobject, id(append),int), d) where id(append) returns an identifier for the method append.

  36. Remote Object Invocatıon (10): Parameter Passing is a problem 2-18 • The situation when passing an object by reference or by value. The distinction in local and global parameters is visible even in object oriented languages. Ref to O1 is by value(L1), reference to O2 is by reference (R1).

  37. The DCE Distributed-Object Model (1) • DCE objects may be accepted as refinement of RPC, with a shift from procedure call to remote method invocation. • DCE distributed objects are specified in IDL and implemented in C++, created by the server making methods available to the clients • Distributed dynamic objects are created by the server only, on clients request and associated with it • Distributed named object is created and registered with a directory service to be shared by more clients Each remote object invocation is done by an RPC , with all the details required as parameters to the object server which maintains an object table with their identifiers and interface identifiers to dispatch the requested methods…. • Binding is done by an handle (in the form of an identifying string), there is no system wide transparent object referencing mechanism. This makes parameter passing in DCE object model harder, as the implementation is some sort of refinement of the RPC parameter passing

  38. The DCE Distributed-Object Model (2) • Distributed dynamic objects in DCE. • Distributed named objects 2-19

  39. Java Distributed Object Model(2) • Implementation of distributed applications in Java is done by means of distributed objects as well. Java remote object is a distributed object whose state is kept on one machine, but the interface is made available to remote processes. • Cloning remote and local objects is not the same. • Java allows each object to be constructed as a monitor, by declaring a method a synchronized. • If two clients simultaneously call a synchronized method one has to wait…However synchronization may be implemented on the local stub (proxy) or the server stub • RMI seems to restrict synchronization, thus blocking, to the client side proxies. • This may not prevent simultaneous access to the remote object, which means explicit distributed locking techniques are required.

  40. Java Distributed Object Model(2) • With RMI, any serializable object can be passed as parameter (platform dependent objects such as file or socket descriptors cannot be serializable). • Local objects are passed by value, remote objects are passed by reference, as in case of DCE objects. • Client and server stubs are generated from the interfaces implemented by the respective classes. • Although, the stubs are serializable objects and they can be marshaled and passed over to servers as remote references, RMI implements stub implementation handlers which are smaller in size as they replace the marshalled code…. • It is also possible to arrange for servers to pass over (downloaded by the clients) marshaled client side code whenever a client binds to the object, which is not possible in DCE object model.

  41. Message Oriented Communication • RPC and RMI type firmware is not always desirable or even practical • In such cases messaging is the way to go! • Subject of concern in communication • Persistence • Transient • Asynchronous • Synchronous

  42. Persistence and Synchronicity in Communication (1) 2-20 • General organization of a communication system in which hosts are connected through a network and messages are passed and queued in an asynchronous manner. • Thus, persistence in comm is achieved.

  43. Example: Persistence and Synchronicity in Communication (2) • Persistent communication of letters back in the days of the Pony Express.

  44. Persistence and Synchronicity in Communication (3) 2-22.1 • Persistent asynchronous communication • Persistent synchronous communication

  45. Persistence and Synchronicity in Communication (4) 2-22.2 • Transient asynchronous communication • Receipt-based transient synchronous communication

  46. Persistence and Synchronicity in Communication (5) • Delivery-based transient synchronous communication at message delivery • Response-based transient synchronous communication

  47. Message Based Transient Communication: Berkely Sockets • Messaging through transport level sockets • Sockets form an interface to transport layer • Socket is an operating system abstraction over the end-to-end communication protocol • UNIX derivative OSs are the first in providing socket interface to TCP of TCP/IP protocol suit • So called, well-known port numbers together with IP numbers are used to bind to a socket…

  48. Berkeley Sockets (1) • Socket primitives for TCP/IP.

  49. Berkeley Sockets (2) • Connection-oriented communication pattern using sockets.

  50. Message-orientedTransient Communication: MPI • Message passing middleware standard • MPI is developed to provide a transport layer independency or more transparency • MPI provides transient communication • MPI library can be tailored to high speed communication, usually provided as proprietary libraries • MPI is developed for parallel application, where each group and a process with the group are assigned identifiers

More Related