1 / 27

Communication II

Communication II. CSE 5306 Lecture Quiz 9 due at 5 PM on Saturday, 13 September 2014. Passing Parameters by Value. The IBM PCs and IBM mainframes represent characters differently; i.e., ASCII and EBCDIC.

kiona
Download Presentation

Communication II

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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.

More Related