Communication TANENBAUMChapter 2 Layered Protocols 1 2 1
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 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
Data Link Layer 2 -3 Discussion between a receiver and a sender in the data link layer.
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. .
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
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
Client-Server TCP 2 -4 a) b) Normal operation of TCP. Transactional TCP.
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…
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…
Middleware Protocols 2 -5 An adapted reference model for networked communication.
Conventional Procedure Call Read(fd, buf, nbytes) a) b) Parameter passing in a local procedure call: the stack before the call to read The stack while the called procedure is active
Client and Server Stubs Principle of RPC between a client and server program.
Steps of a Remote Procedure Call 1. Client procedure calls client stub in normal way 2. Client stub builds message, calls local OS 3. Client's OS sends message to remote OS 4. Remote OS gives message to server stub 5. Server stub unpacks parameters, calls server 6. Server does work, returns result to the stub 7. Server stub packs it in message, calls local OS 8. Server's OS sends message to client's OS 9. Client's OS gives message to client stub 10. Stub unpacks result, returns to client
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 require
Passing Value Parameters (2) • Marshalling is required between two end machines: e. g. Pentium uses Little Ending, Sun uses Big Ending a) b) c) 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…
Parameter Specification and Stub Generation a) b) A n RPC call with different type parameters The corresponding message with special format (IEEE #754).
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
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,
Asynchronous RPC (1) 2 -12 a) b) 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.
Asynchronous RPC (2) 2 -13 A client and server interacting through two asynchronous RPCs: client is interrupted by the server
Distributed Computing Environment(DCE: RPC) q. Services: • Distributed file service • Directory service • Security service • Distributed time service q. Goal: to provide transparency in all above services, including binding, communication, data type conversion, and language differences… q. The DCE RPC includes a number of components including languages, libraries, daemons, and utility programs
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…
Writing a Client and a Server(2) q. 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 q. Interface Definition Language (IDL) file is than allowed to be updated compiled to produce the stubs and the header file q. 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 q. DCE daemon maintains a table for server end points q. A directory server maintains the address of the registered servers with their network addresses.
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…
Remote Object Invocatıon (1) q. Expansion of idea of RPC to method invocations on remote objects to enhance distributed transparency q. 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
Remote Object Invocatıon (2) q Principles of RPC can also be applied to objects q 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 q 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. q 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 unmarshalling, to each others. Note that the object state may or may not be distributed, but if distributed it can be transparent to the application.
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….
Remote Object Invocatıon (4): Compile time vs Runtime Objects 1. The objects implemented using Java and C++ are compile time objects, in which the objects are instances of classes. 2. Compile time objects depend on the particular programming language used. It is easier to built such applications. 3. 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. 4. Adapters should allow an interface to be converted to what the clients expect.
Remote Object Invocation (5): Object Persistence 1. Persistent object continues to exists even if the server cease to exist. 2. A persistent object is saved on the secondary storage by a server and retrieved into the scope of the server, whenever needed. 3. Transient object cease to exist as soon as the servers do so.
Remote Object Invocatıon (6): Object binding 1. In distributed objects case, a system wide object reference is common. 2. Object references can even be passes as parameters in method invocations. 3. A process must first be bound to an object’s reference before invoking any of its methods, perhaps using a proxy. 4. 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.
Remote Object Invocatıon (7): Implementation of Object References q Object reference depicts the address of the server object which include the machine it resides, the server identification, and the object identification q 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 q As a further transparency, an object reference may have additional information, such as the protocols implemented by the object q 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.
Remote Object Invocatıon (8): Binding a Client to an Object Distr_object* obj_ref; obj_ref = …; obj_ref-> do_something(); //Declare a systemwide object reference // Initialize the reference to a distributed object // Implicitly bind and invoke a method (a) Distr_object obj_ref; Local_object* obj_ptr; obj_ref = …; obj_ptr = bind(obj_ref); obj_ptr -> do_something(); //Declare a systemwide object reference //Declare a pointer to local objects //Initialize the reference to a distributed object //Explicitly bind and obtain a pointer to the local proxy //Invoke a method on the local proxy (b) a) b) An example with implicit binding using only global references An example with explicit binding using global and local references
Remote Object Invocation (9): Static vs Dynamic RMI 1. Static remote method invocation implies imbedding the object interfaces into the program, thus requires recompilation if the object interface changes. 2. In dynamic invocation, the method to invoke is selected run time. 3. Example for static rmi: fobject. append (int) 4. Example for dynamic rmi: invoke(fobject, id(append), int), d) where id(append) returns an identifier for the method append.
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 O 1 is by value(L 1), reference to O 2 is by reference (R 1).
The DCE Distributed-Object Model (1) q q 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…. q 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
The DCE Distributed-Object Model (2) a) b) Distributed dynamic objects in DCE. Distributed named objects 2 -19
Java Distributed Object Model(2) q 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. q Cloning remote and local objects is not the same. q Java allows each object to be constructed as a monitor, by declaring a method a synchronized. q 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 q 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.
Java Distributed Object Model(2) q q q 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.
Message Oriented Communication q RPC and RMI type firmware is not always desirable or even practical Ø In such cases messaging is the way to go! q Subject of concern in communication Ø Persistence Ø Transient Ø Asynchronous Ø Synchronous
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.
Example: Persistence and Synchronicity in Communication (2) • Persistent communication of letters back in the days of the Pony Express.
Persistence and Synchronicity in Communication (3) 2 -22. 1 a) b) Persistent asynchronous communication Persistent synchronous communication
Persistence and Synchronicity in Communication (4) 2 -22. 2 c) d) Transient asynchronous communication Receipt-based transient synchronous communication
Persistence and Synchronicity in Communication (5) e) f) Delivery-based transient synchronous communication at message delivery Response-based transient synchronous communication
Message Based Transient Communication: Berkely Sockets 1. Messaging through transport level sockets 1. Sockets form an interface to transport layer 2. Socket is an operating system abstraction over the end-to-end communication protocol 3. UNIX derivative OSs are the first in providing socket interface to TCP of TCP/IP protocol suit 4. So called, well-known port numbers together with IP numbers are used to bind to a socket…
Berkeley Sockets (1) Primitive Meaning Socket Create a new communication endpoint Bind Attach a local address to a socket Listen Announce willingness to accept connections. By allocating enough memory Accept Block caller until a connection request arrives Connect Actively attempt to establish a connection Send some data over the connection Receive some data over the connection Close Release the connection Socket primitives for TCP/IP.
Berkeley Sockets (2) Connection-oriented communication pattern using sockets.
Message-oriented Transient Communication: MPI 1. Message passing middleware standard 1. MPI is developed to provide a transport layer independency or more transparency 2. MPI provides transient communication 3. MPI library can be tailored to high speed communication, usually provided as proprietary libraries 4. MPI is developed for parallel application, where each group and a process with the group are assigned identifiers
The Message-Passing Interface (MPI) Primitive Meaning MPI_bsend Append outgoing message to a local send buffer MPI_send Send a message and wait until copied to local or remote buffer MPI_ssend Send a message and wait until receipt starts MPI_sendrecv Send a message and wait for reply MPI_isend Pass reference to outgoing message, and continue MPI_issend Pass reference to outgoing message, and wait until receipt starts MPI_recv Receive a message; block if there are none MPI_irecv Check if there is an incoming message, but do not block • Examples for some of the most intuitive message-passing primitives of MPI. There are over 100 MPI functions, used especially to improve communication efficiency
Message Queing Model 1. Targeted to support non time critical persistent asynchronous transmission 2. Each receiving application has its own private queue, to which messages are delivered, with no guarantee for when they will be processed 3. The sender and receiver queues need to be globally identified 4. Queues are managed by queue managers 5. So called message brokers can be used to transfer a message into the format acceptable by the end receiver…
Message-Queuing Model (1) 2 -26 • Four combinations for loosely-coupled communications using queues.
Message-Queuing Model (2) Primitive Meaning Put Append a message to a specified queue Get Block until the specified queue is nonempty, and remove the first message Poll Check a specified queue for messages, and remove the first. Never block. Notify Install a handler to be called when a message is put into the specified queue. Basic interface to a queue in a message-queuing system.
General Architecture of a Message-Queuing System (1) • Mapping queue-level names to network locations, same as in DNS. Normally queues are managed by queue managers. Static mapping is easier dynamic mapping is more complex.
General Architecture of a Message-Queuing System (2) 2 -29 • The general organization of a message-queuing system with routers, that know about network topology, where every queue manager needs to know the nearest router, malticasting can also be done.
Message Brokers 2 -30 • The general organization of a message broker in a message-queuing system, used to convert one message format to another. Message broker is an application level message converter. A database should be used to allow rule based format conversions.
Message Brokers (cont. ) • General message queues are aimed to support persistent communication for the end user. • Although e-mail systems behaves similarly they are not to guarantee message delivery, message priorities, logging facilitis, multicasting, load balancing, fault tolerance, etc.
Example: IBM MQSeries 2 -31 • General organization of IBM's MQSeries message-queuing system. a MCA-Message Channel Agent manages two ends of a message channel, • This is primarily aimed at mainframe database applications • Message channels between QM are implemented in TCP connection, and managed by Message Ch Agent-MCA.
Properties of MCA in IBM MQseries Attribute Description Transport type Determines the transport protocol to be used FIFO delivery Indicates that messages are to be delivered in the order they are sent Message length Maximum length of a single message Setup retry count Specifies maximum number of retries to start up the remote MCA Delivery retries Maximum times MCA will try to put received message into queue • Some attributes associated with message channel agents-MCA. Sending and receiving MCAs must be compatible in terms of rules of communication between them
Message Transfer in IBM MQSeries(1) • The general organization of an MQSeries queuing network using routing tables and aliases. • A message header, in addition to the send queue address, has to have the address of the queue manager-QM and the destination queue under that QM
Message Transfer in MQSeries(2) Primitives available in an IBM MQSeries MQI Primitive Description MQopen Open a (possibly remote) queue MQclose Close a queue MQput Put a message into an opened queue MQget Get a message from a (local) queue • Message Queue Interface-MQI is a simple programming interface for the applications. • MQSeries provides these facilities to applications when the messages have arrived
Stream Oriented Communication(1) 1. In digital transmission of video and voice the timing is important. This depend humans’ physical hearing and vision abilities… this is continuous media (CM) domain… The transmission has to be in streams rather than self contained messages. 2. So, which facilities should a distributed system provide for such CM streams transmission: 1. Temporal relationship between different items of CM is crucial for correct interpretation of such data
Stream Oriented Communication(2) q CM is supported by data streams, because of existence of temporal relationship between the data items. q Temporal (time dependent) data transmission is generally provided by so called data streams. Ø Asynchronous tr mode: no limits are defined Ø Synch tr mode: max end-to-end delay is defined Ø Isochronous tr mode: max and min end-to-end delay is defined Ø Complex streams have more than one sub stream, e. g. , stereo audio can have two audio streams… q Streams can be multicast between one source and a number of sinks and filtered if needed…
Data Stream (1) Setting up a stream between two processes across a network.
Data Stream (2) 2 -35. 2 Setting up a stream directly between two devices.
Data Stream (3) An example of multicasting a stream to several receivers.
Stream Comm: Quality of service (Qo. S) q q Qo. S for CM tr can be defined in terms of timeliness, volume, and reliability In addition to time requirements, in an application, using so called bucket algorithm, service requirements may include Ø Ø q q loss sensitivity of data items Minimum delay noticed by the receiver Max delay variation Quality of guarantee Qo. S requires allocation of resources, usually, in terms of processing capacity, bandwidth, buffers… There is no best model for specifying Qo. S parameters Ø Resource re. Ser. Vation Protocol is a transports level for routers to tune to the Qo. S requirements, by the servers.
Specifying Qo. S (1) Characteristics of the Input • maximum data unit size (bytes) • Token bucket rate (bytes/sec) • Token bucket size (bytes) • Maximum transmission rate (bytes/sec) Service Required • Loss sensitivity (bytes) • Loss interval ( sec) • Burst loss sensitivity (data units) • Minimum delay noticed ( sec) • Maximum delay variation ( sec) • Quality of guarantee A flow specification.
Specifying Qo. S (2) • The principle of a token bucket algorithm. Irregular data stream is regulated at the bucket output.
Setting Up a Stream: RSVP-Resource re. Ser. Vation Protocol • The basic organization of RSVP-Resource re. Ser. Vation Protocol- for resource reservation in a distributed system, to achieve the required Qo. S.
Synchronization Mechanisms Example (1) • In multimedia systems this is very important, as more than one stream may come together to meet the application requirements • For example – Two voice streams for stereo voice applications – Presentations slides with voice strams – Video stream with voice stream: lip synchronization! • Synchronization at the lowest level is conducted by the operating system, for example switching between video frames and voice frames, • The low level communication channels must able meet such requirements
Synchronization Mechanisms Example (2) • The principle of explicit synchronization on the level data unit: video and voice
Synchronization Mechanisms using Middleware (3) 2 -41 • The principle of synchronization as supported by high-level interfaces. Different streams are first converted into discrete stream packets, with synchronization information, which can then be multiplexed into one stream as in MPEG-2 standard.
- Slides: 74