Interprocess communication
• Topics
1 Introduction
2 API for Internet Protocols
3 External data representation
4 Client-Server Communication
5 Group communication
6 Unix – An example
Introduction
Focus:
– Characteristics of protocols for communication between processes to
model distributed computing architecture
Effective means for communicating objects among processes at language
level
– Java API
Provides both datagram and stream communication primitives/interfaces –
building blocks for communication protocols
– Representation of objects
providing a common interface for object references
– Protocol construction
Two communication patterns for distributed programming: C-S using
API for Internet
• Characteristics of IPC – message passing using send/receive facilities for sync
and addressing in distributed programs
• Use of sockets as API for UDP and TCP implementation – much more
specification can be found at java.net
• Synchronous communication
– Queues at remote sites are established for message placement by clients (sender). The
local process (at remote site) dequeues the message on arrival
– If synchronous, both the sender and receiver must ‘rendezvous’ on each message, i.e.,
both send and receive invocations are blocking-until
• Asynchronous communication
– Send from client is non-blocking and proceeds in parallel with local operations
– Receive could be non-blocking (requiring a background buffer for when message finally
arrives, with notification – using interrupts or polling) AND if blocking, perhaps, remote
process needs the message, then the process must wait on it
– Having both sync/async is advantageous, e.g., one thread of a process can do blocked receive
while other thread of same process perform non-block receive or are active –
simplifies synchronization. In general non-blocking-receive is simple but complex to
implement due to messages arriving out-of-order in the background buffer
Message destinations
– Typically: send(IP, port#, buffer) – a many-to-one (many senders to a single
receiving port), except multicast, which is many-to-group.
– Possibility: receiving process can have many ports for different message
types
– Server processes usually publish their service-ports for clients
– Clients can use static IP to access service-ports on servers (limiting,
sometimes), but could use location-independent IP by
• using name server or binder to bind names to servers at run-time – for
relocation
• Mapping location-independent identifiers onto lower-level address to
deliver/send
messages – supporting service migration and relocation
– IPC can also use ‘processes’ in lieu of ‘ports’ for services but ports are
flexible
and also (a better) support for multicast or delivery to groups of destinations
Reliability
– Validity: transmission is reliable if packets are
delivered despite some drops/losses, and
unreliable even if there is a single drop/loss
– Integrity: message must be delivered
uncorrupted and no duplicates
Ordering
– Message packets, even if sent out-of-order, must
be reordered and delivered otherwise it is a
failure of protocol
Sockets
– Provide an abstraction of endpoints for both TCP and UDP
communication
– Sockets are bound to ports on given computers (via the
computer’s IP address)
– Each computer has 216 possible ports available to local
processes for receiving messages
– Each process can designate multiple ports for different message
types (but such designated ports can’t be shared with other
processes on the same computer – unless using IP multicast)
– Many processes in the same computer can deliver to the same
port (many-to-one),
however
– Sockets are typed/associated with either TCP or UDP
UDP Datagram communication
– Steps:
Client finds an available port for UPD connection
Client binds the port to local IP (obtained from InetAddress.getByName(DNS) )
Server finds a designated port, publicizes it to clients, and binds it to local IP
Sever process issues a receive methods and gets the IP and port # of sender
(client) along with the message
– Issues
Message size – set to 8KByte for most, general protocol support 216 bytes,
possible truncation if receiver buffer is smaller than message size
Blocking – send is non-blocking and op returns if message gets pass the UDP and
IP layers; receive is blocking (with discard if no socket is bound or no thread is
waiting at destination port)
Timeouts – reasonably large time interval set on receiver sockets to avoid
indefinite blocking
Receive from any – no specification of sources (senders), typically many-to-one,
but one-to-one is possible by a designated send-receive socket (know by both C/S
• UDP Failure Models:
• – Due to Omission of send or receive (either
checksum error or no buffer space
• at source or destination)
• – Due to out-of-order delivery
• – UDP lacks built in checks, but failure can be
model by implementing an ACK mechanism
Client-receiver code
TCP Stream Communication
– Grounded in the ‘piping’ architecture of Unix systems using BSD Unix
sockets for streaming bytes
– Characteristics:
Message sizes – user application has option to set IP packet size, small or
Large
Lost messages – Sliding window protocol with ACKs and retransmission is
Used
Flow control – Blocking or throttling is used
Message duplication and ordering – Seq #s with discard of dups & Reordering
Message destinations – a connection is established first, using connection
accept
methods for rendezvous, and no IP addresses in packets. [Each connection
socket is bidirectional – using two streams: output/write and input/read]. A
client closes a socket to sign off, and last stream of bytes are sent to receiver
with ‘broken-pipe’ or empty-queue indicator
– Other Issues
Matching of data items – both client/sender and server/receiver must agree on
data types and order in the stream
Blocking – data is streamed and kept in server queue: empty server queue
causes a block AND full server queue causes a blocking of sender
Threads – used by servers (in the background) to service clients, allowing
asynchronous blocking. [Systems without threads, e.g., Unix, use select]
– Failure Model
Integrity: uses checksums for detection/rejection of corrupt data and seq #s for
rejecting duplicates
Validity: uses timeout with retransmission techniques (takes care of packet
losses or drops)
Pathological: excessive drops/timeouts signal broken sockets and TCP throws
in the towel (no one knows if pending packets were exchanged) – unreliable
– Uses – TCP sockets used for such services as: HTTP, FTP, Telnet, SMTP
External data representation
Issues
– At language-level data (for comm) are stored in data structures
– At TCP/UDP-level data are communicated as ‘messages’ or streams
of bytes – hence, conversion/flattening is needed
– Problem?
Different machines have different primitive data reps, e.g.,
big-endian and little-endian order of integers, float-type, char codes
– Marshalling (before trans) and unmarshalling (restored to original on
arrival)
– Either both machines agree on a format type (included in parameter
list) or an intermediate external standard (external data rep) is used,
e.g., CORBA Common Data Rep (CDR)/IDL for many languages;
Java object serialization for Java code only, Sun XDR standard for
Sun NFSs
This masks the differences due to different computer
hardware.
CORBA CDR
– only defined in CORBA 2.0 in 1998, before that, each implementation of
CORBA had an external data representation, but they could not generally work
with one another. That is:
the heterogeneity of hardware was masked but not the heterogeneity due to
different programmers (until CORBA 2)
– CORBA CDR represents simple and constructed data types (sequence, string,
array, struct, enum and union)
note that it does not deal with objects (only Java does: objects and tree of objects)
– it requires an IDL specification of data to be serialised
Java object serialisation
– represents both objects and primitive data values
– it uses reflection to serialise and deserialise objects– it does not need an IDL
specification of the objects. (Reflection: inquiring about class properties, e.g.,
