Communication

1
Communication

• Chapter 2

2
Communication

• Layered protocols
• Usual networking approach (client/server)
• Remote Procedure Call (RPC)
• Hide message passing details (client/server)
• Remote Method Invocation (RMI)
• Improved RPC (client/server)

3
Communication

• Message-Oriented Communications
• Message Passing ? Low level, efficient
• Message-Oriented Middleware (MOM) ? Non
  client/server
• Streams
• Continuous flow subject to timing constraints

4
Layered Protocols

• OSI reference model
• Each layer provides service to layer above
• Implementation of service can change

5
Layer Services

• Transport layer
• Logical connection between hosts
• Reliable communication between hosts
• Network layer
• Route packet thru network
• Data link layer
• Get packet over each hop
• Physical layer
• Put the bits on the wire

6
Layered Protocols

• Layered message
• Add headers when msg sent (down protocol stack)
• Peel the onion when msg received (up the protocol
  stack)

7
Data Link Layer

• Communication at data link layer
• Above, A tries to send msgs 0 and 1 to B

8
Network Layer

• On a LAN
• Have a shared media
• Put the packet out, recipient picks it up
• On a WAN
• Have point-to-point communication
• Many possible routes
• Finding best route is difficult

9
Transport Layer

• UDP for unreliable delivery
• Better performance possible with UDP
• TCP for reliable delivery
• May be easier to build app with TCP

10
Client-Server TCP
Transactional TCP
Normal TCP
11
Middleware Protocols

• Reference model for middleware based distributed
  communication

12
What is Middleware?

• Logically at application layer
• General purpose protocols
• Independent of an application
• Well distinguish between
• High level application and
• Middleware

13
Middleware Example

• Often, must authenticate users
• Require users prove identity
• Spse you build authentication system
• Any app can use your auth system
• Your authentication application
• Is at application layer in OSI
• Is also at middleware layer in our view

14
Middleware

• Remainder of this chapter
• 4 middleware communication services
• RPC
• RMI
• Message oriented communication
• Streaming

15
Remote Procedure Call

• Distributed systems can be built on explicit
  message passing
• For example, send and receive
• Whats wrong with this approach?
• Its not transparent to users
• Why should we care?
• Recall that transparency is one of primary goals
  in distributed systems

16
Remote Procedure Call

• RPC is a simple idea
• Make remote operation seem like a (local)
  procedure call
• All the great things are simple ? Winston
  Churchill
• Much better transparency compared to primitive
  message passing
• Can we make remote operation seem local?

17
Conventional Procedure Call

• Consider C function count read(fd, buf, bytes)

• Stack before call to read
• Stack while called procedure is active

18
Parameter Passing

• Consider again
• C function count read(fd, buf, bytes)
• In C, parameters can be
• Passed by value bytes
• Passed by reference the array buf
• Usually not important whether pass by value or
  pass by reference is used
• But its a big deal in RPC!
• Since procedure will execute at remote location

19
RPC between Client/Server

• We say that this is synchronous
• Since client waits for result

20
Stubs

• On client side, stub marshalls parameters and
  send to server
• Pack parameters into message(s)
• On server side, stub converts to local procedure
  call, sends back results
• Stubs increase transparency

21
Passing Value Parameters

• Suppose add(i,j) returns i j
• Remote computation via RPC

22
Client Stub

• Procedure
• Stub marshalls params

23
Steps in RPC

• 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

24
Additional RPC Topics

• Doors
• Caller and sender on same machine
• Asynchronous RPC
• Client does something while server works on
  procedure
• DCE RPC
• Specific implementation of RPC

25
Doors

• If client and server on same machine
• Use interprocess communication (IPC)
• More efficient than network protocols

26
The Doors

• Doors are not to be confused with The Doors

27
Asynchronous RPC

• Usual (synchronous) RPC
• Asynchronous RPC

28
Asynchronous RPC

• Client and server interact via two asynchronous
  RPCs
• More efficient, if applicable

29
DCE RPC

• Distributed Computing Environment (DCE)
• Read this section
• A couple of interesting items
• DCE semantic options
• At-most-once ? no call done more than once, even
  if system crash
• Idempotent ? calls can be repeated multiple times
  (e.g., read)

30
DCE RPC

• Client-to-server binding in DCE
• Note directory service

31
RMI

• Remote Method Invocation
• Distributed objects
• Objects hide internals
• Provides transparency
• Also desirable in distributed systems
• RMI can increase transparency compared to RPC
• Chapter 10 has real systems

32
Objects

• Object encapsulates data, the state
• Object encapsulated methods, operations on the
  data
• Methods are made available thru well-defined
  interfaces
• In distributed environment
• Interface can be on one machine and
• Corresponding object on another machine

33
Distributed Objects

• Interface on client
• Proxy ? like client stub in RPC
• Object on server
• Skeleton ? like server stub in RPC

34
Compile-time vs Runtime

• Compile-time objects
• Objects analogous to those in Java, C
• Pluses easy to implement
• Minuses depends on specific language
• Runtime objects
• Implementation is open, use adapter (wrapper) to
  hide implementation
• Plus and minus opposite of those above

35
RMI and Parameter Passing

• Makes sense to treat local and remote objects
  differently
• Lots of overhead to remote objects
• Pass by reference gets complicated

36
Java RMI

• Distributed objects are an integral part of Java
• Aims for high degree of transparency
• For example client proxy has same interface as
  remote object
• There are subtle differences between local and
  remote objects

37
Java RMI

• Cloning
• Cloning a local object results in exact copy
• Only server can clone remote object
• In Java, proxies not cloned
• So must bind (again) to cloned object
• Can declare method to be synchronized
• Ensures access to data is serialized
• Blocking
• Clients blocked

38
Java RMI

• Read the details
• A preview of Chapter 5
• Spse multiple clients want to access a method on
  server (method is synchronized)
• Block all but one client ? lots of overhead
• Block at the server ? what if client crashes?
• Java restricts blocking to proxies
• Simplifies things
• But then cant prevent simultaneous access of
  remote objects simply by synchronized

39
Message-Oriented Comm.

• RPC and RMI enhance transparency
• But RPC and RMI are inherently synchronous
• Consider an email system where
• Messages stored on email servers when in transit
  and before read
• Stored locally after read
• Example of persistent communication

40
Message-Oriented Comm.

• In email example
• Sender need not continue executing after sending
  msg
• Receiver need not be executing when msg sent
• Comparable to the Pony Express!
• The more things change, the more they stay the
  same

41
Pony Express

• Persistent comm and the Pony Express

42
Transient and Asynchronous

• Transient
• Msg is stored only as long as sender and receiver
  are alive
• If msg cant be delivered, discard it
• Asynchronous
• Sender does not wait for response before
  continuing
• Recall persistent and synchronous
• Four possible combinations

43
Examples

• Transient asynchronous
• UDP
• Transient synchronous
• Synchronous RPC
• Persistent asynchronous
• email
• Persistent synchronous
• Msg can only be stored at receiving host

44
Persistence and Synchronicity

• Persistent asynchronous communication
• Persistent synchronous communication

45
Persistence and Synchronicity

• Transient asynchronous communication
• Receipt-based transient synchronous communication

46
Persistence and Synchronicity

• Delivery-based transient synchronous
  communication at message delivery
• Response-based transient synchronous communication

47
Message-Oriented Comm.

• Message-oriented systems take transient
  asynchronous as baseline
• Like UDP
• But persistence sometimes needed
• Especially if geographically distributed
• Network or process failures likely
• Message passing like transport layer

48
Message-Oriented Comm.

• Transient
• Berkeley sockets
• Message Passing Interface (MPI)
• Persistent
• Message queuing model, MOM
• Message brokers

49
Berkeley Sockets

• Socket primitives for TCP/IP

50
Berkeley Sockets

• Connection-oriented communication pattern using
  sockets
• Note synchronization point

51
Message-Passing Interface (MPI)

• A few (of the many) MPI primitives
• Emphasis here is on efficiency
• Big parallel machines use MPI

52
Message-Passing Interface (MPI)

• Transient asynchronous MPI_bsend
• Transient synchronous MPI_ssend
• Stronger form of synchronous MPI_sendrecv
• Many more possibilities (read the book)

53
Message Queuing

• Persistent
• Message-Queuing Systems or MOM
• Insert msgs into queues
• Delivered via a series of servers
• Can be delivered even if server down
• No guarantee msg will be delivered
• No assurance msg will be read, etc.
• For systems where communications takes minutes
  instead of milliseconds

54
Message-Queuing Model

• Loosely-coupled communications using queues

55
Message-Queuing Model

• Simple interface to message-queuing system
• Put is non-blocking
• Get blocks only if queue is empty
• Poll is non-blocking form of Get

56
Message-Queuing System

• Addressing in message-queuing system

57
Message-Queuing System

• Routing in message-queuing system

58
Message Brokers

• Message broker in message-queuing system
• Translates between msg formats

59
Example IBM MQSeries

• Read it

60
Streams

• Other methods based on more-or-less independent
  units of data
• Timing does not affect correctness
• In multimedia, timing is critical
• Audio and video
• Can tolerate loss, but not jitter
• Temporal relationship is important

61
Stream Transmission Modes

• Asynchronous transmission mode
• Data sent one after another
• No other timing constraints
• Synchronous transmission mode
• Max end-to-end delay for each unit
• Isochronous transmission mode
• Max and min end-to-end delay

62
Stream

• Stream from process to process
• Stream can be viewed as a virtual connection
  between source and sink

63
Stream

• Stream sent directly between two devices

64
Stream

• Multicasting a stream
• Different requirements for receivers?

65
Specifying QoS

• A flow specification

66
Specifying QoS

• A token bucket algorithm
• Dont want bucket to be empty of overflowing
• Then can feed out at precise time intervals

67
Setting Up a Stream

• RSVP for resource reservation
• Purpose is to try to insure QoS
• Highly dependent on data link layer

68
Synchronization

• Explicit synchronization for data units
• Read and write incoming stream units
• App is responsible for sync., only low-level
  utilities

69
Synchronization

• Synchronization supported by high-level
  interfaces
• A middleware approach

70
Summary

• Communication is a fundamental issue in
  distributed systems
• Networking overview
• RPC
• Goal is transparency
• RMI
• Transparency and objects
• RPC and RMI are synchronous

71
Summary

• Recall
• Synchronous ? block until msg delivered (or until
  response received)
• Asynchronous ? sender continues immediately after
  sending
• Persistent ? msg stored until delivered
• Transient ? msg delivered now or never

72
Summary

• Message-Oriented Communication
• Message passing
• For transient asynchronous (MPI)
• Good for big parallel machines
• Message-oriented middleware (MOM)
• Designed for persistent asynchronousStreams
• Streams
• Primarily for video and audio
• Temporal relationship is critical