Communication II

1. Communication II CSE 5306 Lecture Quiz 9 due at 5 PM on Saturday, 13 September 2014

2. 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 (msbright). (Strings in both read left to right.) • RPC’s client stub and server stub must translate.

3. 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.

4. Parameter Specification and Stub Generation • An Interface Definition Language (IDL) fully describes the client stub’s represen-tations 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., connection-oriented TCP/IP. foobar( char x; float y; int z[5] ) { … };

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?

6. R U O K ? 1. Which of the following problems arise in RPCs’ passing parameters by value? __ • Characters may be represented differently. • A client’s array pointer is meaningless in the remote server’s address space. • Data bytes may be arranged in different orders. • All of the above. • Both a and c above.

7. R U O K ? 2. Which of the following problems arise in RPCs’ passing parameters by reference? __ • Characters may be represented differently. • A client’s array pointer is meaningless in the remote server’s address space. • Data bytes may be arranged in different orders. • All of the above. • Both a and c above.

8. R U O K ? 3. Which of the following is specified by the middleware’s Interface Definition Language? __ • The character code used in all names. • Types of all parametersand the floating point representation standard. • Data byte sequence. • Network protocols. • All of the above.

9. R U O K ? 4. Which of the following accurately characterizes RPC dialogs? __ • In an asynchronous RPC, the server stub immediately acknowledges the client stub’s request and releases the client to resume execution. • In a deferred synchronous RPC, the server also calls back the previously released client with results later on. • 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. • All of the above. • None of the above.

10. 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.

11. 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.

12. Writing a Client and Server • 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.

13. Binding a Client to a Server • A server must be registered before clients call. • DCE daemons have (server, end point) tables. • A new server provides lists of its end points, protocols and services to its DCE daemons. • It registers network addresses of its machine and itself with DCE’s directory service. • Then server and client may bind.

14. Performing an RPC • App does RPC. • Client stub marshals parameters. • Runtime library sends message ro server stub. • Server stub unmarshals parameters and calls server. • Reply returns via reverse route. • If remote procedure is marked “idempotent,” process can repeat in case server crashes.

15. R U O K ? 5. Which of the following servers already are available within the Distributed Computing Environment (DCE) middleware? __ • A worldwide distributed file service. • A worldwide directory service for printer access. • A security service to authorize resource users. • A distributed time service to synchronize the clocks of every DCE-administered middleware. • All of the above.

16. R U O K ? 6. Which of the following were goals of those who created DCE’s RPC service? __ • Give global reach to simple, legacy, local procedures. • Make all bindings and communications details transparent. • Minimize users’ interventions and required knowledge. • All of the above. • None of the above.

17. R U O K ? 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. __

18. R U O K ? 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. __

19. R U O K ? 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. __

20. 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.

21. 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.

22. 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: • 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.

23. 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.

24. R U O K ? 22. Why NOT use remote procedure calls and remote object invocations for transparent message-oriented transient communications among distributed systems? __ • 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. • All of the above. • None of the above.

25. R U O K ? 23. Why NOT use TCP/IP for transparent message-oriented transient communications among distributed systems? __ • Sockets (i.e., communications end points) compromise highly optimized multicomputer performance. • Simple send and receive primitives lack access transparency. • General purpose TCP/IP protocols are too slow. • All of the above. • None of the above.

26. R U O K ? 24. Why does MPI serve the high-performance multicomputer best? __ • Its efficient primitives are perfect for parallel apps’ transient communications. • Its group and process IDs are conveniently limited in scope. • It enables flow-control buffering and precise synchronization. • It squeezes all highly-optimized proprietary libraries into one portable protocol. • All of the above.

27. R U O K ? Match the following primitives with their definitions below. 25. Bind __ 26. MPI_bsend__ 27. MPI_irecv__ 28. MPI_send__ 29. MPI_sendrecv__ • Enable transient asynchronous communications by asking OS to hold message till receiver sends MPI_recv. • Block sender till receiver calls. • Like a normal RPC. • An asynchronous receiver inviting other’s messages. • Attach a local address to a TCP/IP socket.