Chapter 4 Chapter 4 Interprocess Communication

farflungconvyancerΛογισμικό & κατασκευή λογ/κού

2 Δεκ 2013 (πριν από 3 χρόνια και 10 μήνες)

108 εμφανίσεις

Chapter4
Chapter

4
Interprocess Communication
Copyright © 2005 Prof. Amr El-Kadi
O
O
utline

Introduction

The API for the Internet Protocols

External Data Representation and
Marshalin
g
g

Client-Server Communication

オﵭ北說

オ

ﵭ北說

Case Study: interprocess
communicationinUNIX
Copyright © 2005 Prof. Amr El-Kadi
communication

in

UNIX
Introduction
Applications, services
Middleware
re
q
uest-re
p
l
y

p
rotocol
This
RMI and RPC
layers
qpyp
marshalling and external data representation
UDPdTCP
This
chapter
UDP
an
d

TCP
Copyright © 2005 Prof. Amr El-Kadi
The API for the Internet
Protocols

Synchronous and asynchronous
communication.

Message destinations.

ﱩ塞若

ﱩ塞若


Ordering.
Copyright © 2005 Prof. Amr El-Kadi
S
S
ockets
message
agreed port
any port
socketsocket
message
other ports
client
server
Internet address = 138.37.88.249Internet address = 138.37.94.248
Copyright © 2005 Prof. Amr El-Kadi

The same socket may be used both for
sendin
g
and receivin
g
of messa
g
es.
ggg

Each socket is associated with exactly
oneprotocol(ieUDPorTCP)
one

protocol

(i
.
e
.,
UDP

or

TCP)
.
Copyright © 2005 Prof. Amr El-Kadi
External Data Representation
and Marshaling

Flattening of data.

What is marshalin
g
and unmarshalin
g
?
gg

CORBA’s Common Data Representation
(CDR) and Sun XDR, for use by a variety of
programming languages.

Java’s Object Serialization, for use only by
Java.

Both marshal data in binary form (as
dhASCII
bdhd
Copyright © 2005 Prof. Amr El-Kadi
oppose
d
to t
h
e
ASCII
-
b
ase
d
approac
h
use
d

by HTTP).
COC
CO
RBA’s
C
DR
T
y
p
e
R
e
p
rese
n
t
a
t
i
o
n
sequencelength(unsignedlong) followed byelementsin order
s
t
ri
n
g
l
e
n
g
t
h
(
u
n
si
g
n
ed
l
o
n
g
)

f
o
l
lowed
b
y
charac
t
ers
i
n
order
(
ca
n
also
g
g
(
g
g
)
f
y
(
canhave widecharacters)
arrayarray elements inorder (no length specified because it is fixed)
h
d
f
d
l
f
h
s
t
ruct
i
n
t
h
e or
d
er o
f
d
ec
l
arat
i
o
n
o
f

t
h
eco
m
po
n
e
n
t
s
enumeratedunsignedlong (the values arespecified by theorder declared)
uniontype tag followed by the selected member
Copyright © 2005 Prof. Amr El-Kadi
OS
Java
O
bject
S
erialization

In Java RMI, both objects and primitive
data values ma
y
be exchan
g
ed.
yg

Java supports reflectionand it uses it
inserializationanddeserialization
in

serialization

and

deserialization
.
Copyright © 2005 Prof. Amr El-Kadi
Client-Server Communication

An interprocess communication protocol built
over UDP avoids the overheads associated with
TCPespecially:
TCP
,
especially:

It avoids acknowledgments since requests are
followed by replies;

Establishment of a connection;

Flow of control that is considered redundant for the
majorityofinvocationsthatpassonlysmall
majority

of

invocations

that

pass

only

small

arguments and results.

Most RMI and RPC systems are supported by
th
t
l
tl
Copyright © 2005 Prof. Amr El-Kadi
th
e reques
t
-rep
l
ypro
t
oco
l

Request
ServerClient
Request
doOperation
(wait)
getRequest
execute
message
select object
(wait)
(continuation)
Reply
message
execute
method
sendReply
Copyright © 2005 Prof. Amr El-Kadi
Operations of the Request-Reply
Protocol
public byte[] doOperation (RemoteObjectRef o, int methodId, byte[] arguments)
sends a request message to the remote object and returns the reply.
The arguments specify the remote object, the method to be invoked and the
fhhd
arguments o
f
t
h
at met
h
o
d
.
public byte[] getRequest ();
acquires a client request via the server port.
p
ublic void sendRe
p
l
y

(
b
y
te
[]
re
p
l
y,
InetAddress clientHost
,
int clientPort
);
ppy(y[]py,,);
sends the reply message reply to the client at its Internet address and port.
Copyright © 2005 Prof. Amr El-Kadi
Request-reply message structure
m
essageType
requestId
i
nt (0=Request, 1= Reply)
int
objectReference
methodId
R
emoteObjectRef
int or Method

Thisschemerequiresthateachmessagehavea
arguments
array of bytes

This

scheme

requires

that

each

message

have

a

unique message identifierthat has two parts:
1.
a requestID,
Copyright © 2005 Prof. Amr El-Kadi
2.
an ID for the sender process
Failure model for the request-
reply protocol

UDP suffers from:
1.
Omission failures,
2.
Out of order message delivery,

UDP uses timeoutsto deal with
server failures or the dropping of
re
q
uest or re
p
l
y
messa
g
es.
qpyg
Copyright © 2005 Prof. Amr El-Kadi

To deal with duplication of requests,
the protocol filters successive
messages from the same sender by
using the request identifier.

How does it deal with losing reply
messages? (Idempotent operations)

What if the operations are not
idempotent? (History)
Copyright © 2005 Prof. Amr El-Kadi
C
RP
C
exchange protocols
Name
Messages sent by
Client
ServerClient
R
R
e
qu
es
t
R
e
qu
es
t
RR
Request
Reply
R
R
A
Request
R
e
p
l
y
Ack
n
o
w
l
edge re
p
ly
Copyright © 2005 Prof. Amr El-Kadi
GC
G
roup
C
ommunication

Multicasting provides a useful
infrastructure for constructing distributed
systems with the following
characteristics:
1.
Fault tolerant based on replication of services;
2.
Providing discovery of service;
3.
Replicate data to improve performance;
4.
Provide event notification.
Copyright © 2005 Prof. Amr El-Kadi
Case Study: interprocess
communication in UNIX

Those are based on the socketabstraction.

The socketsystem call creates a socket for a
processItreturnsasocketdescriptor
process
.
It

returns

a

socket

descriptor
.

The socket lasts until it is closedor until every
process having its descriptor exists.

The recipient process must bin
d
its socket
descriptor to a socket address (same is true for a
sender if it expects replies). The bindsystem call is
used for this purpose.

Note that the address of a socket cannot change
once its bound.
Copyright © 2005 Prof. Amr El-Kadi
Datagram communication
Sending a messageReceiving a message
s
=
socket(AFINET,SOCKDGRAM,0)
s = socket
(
AFINET
,
SOCKDGRAM
,
0
)
bind(s, ClientAddress)bind(s, ServerAddress)
s

socket(AF
_
INET,

SOCK
_
DGRAM,

0)
(
_
,
_
,)
sendto(s, "message", ServerAddress)amount = recvfrom(s, buffer, from)
ServerAddress and ClientAddress are socket addresses
Copyright © 2005 Prof. Amr El-Kadi
S
S
tream communication
Thibdh
i
fhii

Th
ere
i
s a
b
oun
d
on t
h
e s
i
zeo
f
t
h
e rec
i
p
i
ent
queue. The sender blocksif the queue is full.

﹯ﱹ
オﱤﱩョ

﹯ﱹ







ﱩ



ョ

葉﹮ョﰠ若オﱤ﹥
」ュﵵ﹩若便ﹴ﹧
ﹴﱩ葉
エ便ﹴ


ﹴ

ﱩ葉



エ

便ﹴ


When a connection is accepted, UNIX
automatically creates a new socket and pairs it
iththlit’ktthtthld
w
ith

th
e c
li
en
t’
s soc
k
e
t
so
th
a
t

th
e server wou
ld

continue listening for other clients using the
original socket.
Copyright © 2005 Prof. Amr El-Kadi

The listenoperation is used to listen and
specifies the size of the queue.

The client process uses connectsystem
call to re
q
uest a connection via the
q
socket address and no prior binding is
needed as it automatically binds the
client’s socket name to its socket.
Copyright © 2005 Prof. Amr El-Kadi
Sf
S
ockets used
f
or streams
Requesting a connectionListening and accepting a connection
s
=
socket(AFINET,SOCKSTREAM,0)
s = socket
(
AFINET
,
SOCKSTREAM
,
0
)
bind(s, ServerAddress);
listen(s,5);
sNew = acce
p
t
(
s
,
ClientAddress
);
s

socket(AF
_
INET,

SOCK
_
STREAM,0)
connect(s, ServerAddress)
(
_
,
_
,)
p(,);
n = read(sNew, buffer, amount)
write(s, "message", length)
ServerAddress and ClientAddress are socket addresses
Copyright © 2005 Prof. Amr El-Kadi