Transcript CSE5306Lecture20150211

4.2.2 Communication II
CSE5306 Lecture
Quiz 9 due 5 PM
Tuesday, 10 February 2015
Passing Parameters by Value
• The IBM PCs and IBM mainframes represent
characters differently; i.e., ASCII and EBCDIC.
• Intel and SPARC order data bytes differently; i.e.,
little- (lsb right) and big-endian (msb right).
(Strings in both read left to right.)
• RPC’s client stub and server stub must translate.
Passing Parameters by Reference
• The client’s pointer is meaningless in the
server’s address space.
• Instead of passing a pointer, the client stub
passes the actual buffer full of data.
• Or the client stub is passes the size of the
buffer, if it wants the server to return data.
Parameter Specification
and Stub Generation
• An Interface Definition
Language (IDL) fully describes
the client stub’s representations for the server stub:
– Character code used in
procedure name; e.g., ASCII.
– Types of all parameters; e.g.,
INT32.
– Floating point representation;
e.g., IEEE Std 754.
– Data byte sequence; e.g., little
endian.
– Network; e.g., connectionoriented TCP/IP.
foobar( char x;
float y; int z[5] )
{…
};
Asynchronous RPC
• No server response is required when transferring
money, adding to a database, starting a remote
service or batch processing.
• In an asynchronous RPC, the server stub
acknowledges the client stub’s request and
releases the client to resume execution.
• In a deferred synchronous RPC, the server also
calls the client back later with results.
• In a one-way RPC, the client does not even wait
for the server’s acknowledgement, but what if
the client’s request was not received?
RUOK?
1. Which of the following problems arise in RPCs’
passing parameters by value?
a. Characters may be represented differently.
b. A client’s array pointer is meaningless in the
remote server’s address space.
c. Data bytes may be arranged in different orders.
d. All of the above.
e. Both a and c above.
RUOK?
2. Which of the following problems arise in RPCs’
passing parameters by reference?
a. Characters may be represented differently.
b. A client’s array pointer is meaningless in the
remote server’s address space.
c. Data bytes may be arranged in different orders.
d. All of the above.
e. Both a and c above.
RUOK?
3. Which of the following is specified by the
middleware’s Interface Definition Language?
a. The character code used in all names.
b. Types of all parameters and the floating point
representation standard.
c. Data byte sequence.
d. Network protocols.
e. All of the above.
RUOK?
4. Which of the following accurately characterizes RPC
dialogs?
a. In an asynchronous RPC, the server stub immediately
acknowledges the client stub’s request and releases the
client to resume execution.
b. In a deferred synchronous RPC, the server also calls back
the previously released client with results later on.
c. In a one-way RPC, the client does not even wait for the
server’s acknowledgement, fully confident that the
client’s request (e.g., money transfer, database entry,
starting a remote service, batch processing) was received.
d. All of the above.
e. None of the above.
Introduction to DCE
• The Distributed Computing Environment (DCE)
is a middleware that runs between distributed
applications and a network operating system.
• All client-server communications are via RPCs.
• Many servers are within DCE:
– Distributed file service accesses files worldwide.
– Directory service accesses global printers, etc.
– Security service authorizes resource users.
– Distributed time service synchronizes all clocks.
Goals of DCE RPC
• Give simple, legacy, local procedures global reach.
• Hide all bindings and communications details.
• Client and server can be…
–
–
–
–
–
Written in different languages; e.g., Java, C.
Run on different hardware; e.g., Intel, IBM.
Run with different OSes; e.g., UNIX, VMS, Windows.
Using different data representations; e.g., ASCII.
Running different network protocols; e.g., TCP/IP.
• …entirely without user’s intervention/knowledge.
Writing a Client and Server
1.
2.
3.
4.
5.
6.
7.
Write IDL function declarations (like C function prototypes).
Marshall parameters; i.e., pack them into messages.
Ask uuidgen for globally unique interface names (32-hex digits).
Add to client stub the names of all remote procedures to be called.
Add to server stub all required runtime system procedure names.
IDL compiler generates header file and client and server stubs.
Write the client and server apps.
Binding a Client to a Server
1. A server must be registered before clients call.
2. DCE daemons have (server, end point) tables.
3. A new server provides lists of its end points,
protocols and services to its DCE daemons.
4. It registers network addresses of its machine
and itself with DCE’s directory service.
5. Then server and client may bind.
Performing an RPC
1.
2.
3.
4.
App does RPC.
Client stub marshals parameters.
Runtime library sends message ro server stub.
Server stub unmarshals parameters and calls
server.
5. Reply returns via reverse route.
6. If remote procedure is marked “idempotent,”
process can repeat in case server crashes.
RUOK?
5. Which of the following servers already are
available within the Distributed Computing
Environment (DCE) middleware?
a. A worldwide distributed file service.
b. A worldwide directory service for printer access.
c. A security service to authorize resource users.
d. A distributed time service to synchronize the
clocks of every DCE-administered middleware.
e. All of the above.
RUOK?
6. Which of the following were goals of those who
created DCE’s RPC service?
a. Give global reach to simple, legacy, local
procedures.
b. Make all bindings and communications details
transparent.
c. Minimize users’ interventions and required
knowledge.
d. All of the above.
e. None of the above.
RUOK?
Arrange the following steps for writing a DCE RPC client and
server in their proper order.
7. Write all IDL function declarations.
__
8. After the IDL compiler generates header file and client and
server stubs, write all client and server apps.
__
9. Marshall parameters; i.e., pack them into messages. __
10. Add to client stub the names of all remote procedures to
be called, and add to server stub all required runtime system
procedure names.
__
11. Get globally unique interface names (32-hex digits) from
uuidgen.
__
RUOK?
Arrange in proper order the following steps for binding a
DCE RPC client to its server.
12. Client tests all of the above by doing an RPC.
__
13. Register service with remote directory server. __
14. Client asks DCE daemon for server’s end point. __
15. Register server end point with local DCE daemon. __
16. Client looks up server on directory server.
__
RUOK?
Arrange in proper order the following steps for
performing an RPC.
17. Client stub marshals parameters. __
18. App issues RPC to its local OS.
__
19. Server’s reply returns to app via reverse route.
__
20. Runtime library sends message to server stub.
__
21. Server stub un-marshals parameters and calls
server.
__
Message-Oriented Communication
• Remote procedure calls and remote object invocations
enhance access transparency by hiding distributed
systems’ communications.
• But sometimes your friend is not available when you
call.
• Blocking your progress till she responds would reduce
your performance.
• RPCs and ROIs are synchronous—sometimes we need
the asynchrony of emails.
• Plugging directly into the transport layer’s socket
enables a distributed system to do message-oriented
transient communications.
Berkeley Sockets
• A “socket” is an (abstract) communications end point, where an
application can directly write to and read from another networked
application.
• Berkeley UNIX offers a set of primitives to make use of the TCP/IP’s
messaging protocols.
TCP/IP vs. MPI
• Sockets reduce multicomputer performance:
– Simple send and receive lack access transparency.
– General purpose TCP/IP protocols are too slow.
• MPI handles advanced multicomputer features:
–
–
–
–
–
–
–
–
MPI = Message Passing Interface (pp.142-5).
Suited for parallel apps’ transient* communications.
Small group and process ID numbers for processes.
Flow-control buffering and precise synchronization.
Does not automatically recover from process crashes.
Many efficient application-level primitives.
Makes the many proprietary libraries compatible.
All proprietary library features—bloated or highly optimal
performance?
*Message stored only while sender and receiver are both running.
The Message-Passing Interface (MPI)
• MPI_bsend enables transient asynchronous
communications by asking OS to hold message till
receiver sends MPI_recv. (Can ask if done.)
• MPI_send blocks sender till receiver calls.
• MPI_sendrecv is a normal RPC.
• MPI_irecv says asynchronous receiver welcomes
messages.
RUOK?
22. Why NOT use remote procedure calls and remote
object invocations for transparent message-oriented
transient communications among distributed systems?
a. Sometimes your friend is not available when you call.
b. Blocking your progress till she responds would reduce
your performance.
c. RPCs and ROIs are synchronous—sometimes we need
the asynchrony of emails.
d. All of the above.
e. None of the above.
RUOK?
23. Why NOT use TCP/IP for transparent messageoriented transient communications among distributed
systems?
a. Sockets (i.e., communications end points)
compromise highly optimized multicomputer
performance.
b. Simple send and receive primitives lack access
transparency.
c. General purpose TCP/IP protocols are too slow.
d. All of the above.
e. None of the above.
RUOK?
24. Why does MPI serve the high-performance
multicomputer best?
a. Its efficient primitives are perfect for parallel
apps’ transient communications.
b. Its group and process IDs are conveniently
limited in scope.
c. It enables flow-control buffering and precise
synchronization.
d. It squeezes all highly-optimized proprietary
libraries into one portable protocol.
e. All of the above.
RUOK?
Match the following primitives with their definitions below.
25. Bind
__
26. MPI_bsend
__
27. MPI_irecv
__
28. MPI_send
__
29. MPI_sendrecv __
a. Enable transient asynchronous communications by asking
OS to hold message till receiver sends MPI_recv.
b. Block sender till receiver calls.
c. Like a normal RPC.
d. An asynchronous receiver inviting other’s messages.
e. Attach a local address to a TCP/IP socket.