Lecture Outline

Aims and Objectives
Issues
OSI in a nutshell
Asynchronous Transfer Mode (ATM) Networks in a nutshell
The Client-Server Model in a nutshell
Remote Procedure Call in a nutshell
Group Communication

• Issues

• Platforms for interprocess Communication

  Open Systems Interconnection
  Asynchronous Transfer Mode
  Client-Server Model
  Remote Procedure Calls
  Group Communication
  

• Processes which execute on CPUs sharing memory can easily communicate, but what about processes executing on CPUs which don't share memory?

• How to implement message passing (communication)

• Speed of communication

• Reliability of communication

• Transparency of communication

• Locating the right process to communicate with

• Consistency of Communication

• Defines a standard for open systems to communicate

• 2 Generic Types

  Connection-oriented

  Connectionless

• OSI generally gives users/applications the impression that connection-oriented communication is provided

• What happens in lower layers in the model is hidden from users/applications

7. The Application Layer

• High-level application protocols, e.g., e-mail, video conferencing, file transfer, etc.

6. The Presentation Layer

• Concerned with the meaning of bits in the message

• Notifies receiver that message contains a particular record in a certAin format

5. The Session Layer

• Provides dialog control and synchonisation facilities

• Checkpointing can be used so that after recovering from a crash transmission can resume from the point just before the crash

• Rarely used

4. The Transport Layer

• Provides a mechanism to assure the Session Layer that messages sent are all received without any data corruption or loss

• Breaks message from Session Layer into appropriate chunks (e.g., IP Packets), numbers them and sends them all

• Communicates with receiver to ensure that all have been received, how many more the receiver can receive, etc.

• Determines route (next hop) message will take to bring it closer to its destination

• Detects and corrects data transmission errors (data corruption, missing data, etc.)

• Gathers bits into frames and ensures that each frame is received correctly

• Sender puts special bit pattern at the start and end of each frame + a checksum + a frame number

1. The Physical Layer

• Concerned with Transmitting Bits

• Standardizes the electrical, mechanical and signalling interfaces

• Advances in network technology introduce high-speed networks capable of transfering multimedia data at rates of 155 Mbps and up, using either point-to-point and/or broadcast communications

• Can now implement high-bandwidth distributed systems

• ATM grew out of a need for a single network capable of carrying data in low constant data rates (e.g., voice) and bursty data traffic

• ATM carries fixed-sized blocks (cells) over virtual (connection-oriented) circuits

• When two or more computers need to communicate, the sender first establishes a connection. The network helps to determine the route and then future conversations are carried over the same route, until the connection is dropped

• The routing information is stored in switches. When the connection is dropped, the routing information in the switches is purged

• The OS is structured as a group of cooperating processes (servers) that offer services to users (Clients)

• Clients and Servers run the same microkernel

• Connectionless request/reply protocol used

• Client requests a service from a server using send(dest, &mptr). Server waits for a message to be recieved using receive(addr, &mptr), performs the task and sends the data or error code

• No overheads of setting up/dropping a connection, passing messages through multiple layers, etc.

• A name server is used for clients to determine the machine running the process with which they want to communicate

• Programs on one computer are allowed to call procedures located on other computers

• Identical to one program calling another on the same machine (with parameters, return results, etc.)

• Problems...
  • Processes don't share memory

  • Locating the machine running the procedure

  • Machines involved can use different microkernels

  • Reference parameters

  • One of the machines might crash

• On machine 1, program rand is replaced by a client stub

• Machine 2 has both a server stub for rand as well as the rand procedure

• Machine 1 doesn't realise that rand is located on a different machine

• rand on machine 2 doesn't realise that it has been called by a procedure on a remote machine

• The client stub packs the parameters (including the procedure name) into a message (parameter marshalling) and passes the message to machine 2. The client then waits to receive the result

• The server stub for rand will have been waiting to receive a message. When one arrives, it unpacks the parameters and calls the rand procedure. The procedure returns the result to the server stub which sends the new message back to the client. When the client stub for rand receives the message, it unblocks, unpacks the message and passes the result to the calling procedure

Parameter Passing in RPC

• What if seed had been passed by reference instead of by value?

• Option 1: Forbid Call-by-Reference

• Option 2: Simplest way is client stub to allow calling procedure to use reference parameters, but during parameter marshalling to replace the reference with the actual value

  ok for small amouts of data, client stub will place the results in the appropriate memory locations on receiving them. Call-by-Copy/Restore

  bad for pointers to complex data types

• Optimise above depending on whether remote procedure will read from or write to the address

• Option 3: Flexible, but inefficient method is to simply send server stub the address in the message. Server stub will realise it's a pointer and will send a request to the client for the data at that memory location, etc...

Clients-Servers use different microkernels

• Can be a major problem as different architectures can expect data to be encoded differently (character codes, representations, etc.)

• Simplest thing to do is allow each client to use its native format, and identify the format in the first byte of the message.

• Receiving server converts the data to its own format if it needs to

Dynamic Binding

• One or more computers act as a binder

• When RPC servers are started up they register with the binder

• When a client wants to perform an RPC it asks the binder for the server's address

• Using one machine as the binder means that if it crashes, clients can find servers

• If multiple machines are used as binders, there is overhead keeping them consistent

Dealing with Failures

• Several types of failure

  Client unable to locate server

  Request message from client to server is lost

  Reply message from server to client is lost

  Server crashes after receiving request

  Client crashes after sending request

• The models discussed previously mainly dealt with point-to-point communications

• What if communication involves multiple processes that need to synchronise their execution?

• For example, a fault-tolerant file service incorporating multiple file servers

• All members of the group need to receive the message in one operation, and possibly in the correct sequence

• Groups are dynamic

• How can members of a group all receive the same message?

  Group organisation and Group Management: Peer-to-Peer or Hierarchical

• How can messages be guaranteed to be received correctly and in the right order?

  Atomic Broadcast: All machines received message or none of them do. All-or-nothing

  Consistent Time ordering: pick one of several messages received "at the same time" and deliver it first

Next Lecture...

Synchronisation in Distributed Operating Systems