1. RPC Project Using either sockets or TLI, implement Remote Procedure Calls between two distinct machines that are communicating over an Ethernet network Note that procedures in this sense are really functions – functions return a value whereas procedures do not Remote functions can pass any number of parameters (including 0) and all parameters are passed by value

2. Calls function foo on workstation 2 (ws2) from workstation 1 (ws1) ws2:foo(a,b,c); ws2: is a stub function that receives foo(a,b,c) as argv/argc The stub function ws2: – marshals function name and function parameters into data packet –establishes socket connection with server (workstation 2) –sends data packet over socket link –waits for reply from server (reply is a data packet with function return value) –receives reply data packet from server –un-marshals data packet –prints out function return value to standard I/O Actions at Calling Terminal

3. Actions at Called Terminal Invoke daemon monitor to listen for socket communications from client – the daemon will: –Receive marshaled request –Un-marshal request –Assemble request into local function call with parameters –Make local function call –Receive return value –Marshal return value into data packet –Send data packet over network using sockets

4. Protocol for RPC Client Process rpc rpc call return marshaled marshaled request return client kernel logical call logical return network Server Process ordinary ordinary call return marshaled marshalled request return server kernel client program client Stubserver stub server functions network services

5. Corrections I was wrong when I indicated that the remote function would be called from the command prompt at the client terminal. In reality, it should be called from a program running on the client terminal I was also wrong when I said the server’s forked child would probably execute the function with an exec. After marshaling at the server the call will be made like a normal function call.

6. Other Requirements You should make at least three different RPC calls, one with no parameters, one with one parameter, and one with multiple parameters. The minimum RPC project requirements is to make an RPC call from a host machine that prints out something on a remote machine such as “hello world” You will not get an A+ by doing the minimum requirements, but you will satisfy the project requirement

7. Other Requirements (cont) You must use sockets, TLI or a similar network protocol that is the level of difficulty of the sockets and TLI we have studied in the book. Do not use STREAMS You must marshal the function name and parameters at the client, use system calls (i.e., sockets) to pass them over the network, un- marshal them at server, form the function name and parameters into a function call, marshal the function return value at the server, pass the return value over the network, un-martial the return value at the client, and use the return value in the calling program’s mathematical expression

8. Other Requirements (cont) It is O.K. with me if you write your code so that parameters and the return value are either integer, floating point or void type I will accept integer or void types as the minimum requirements

9. Other Requirements (cont) You can run and test your RPC program on a single workstation The client stub should be written as a separately compiled module and the server stub should be written as a background daemon A short program will have an RPC call in it that makes a call to the client stub and passes the function call to the stub as parameters The server should either fork processes to handle client requests or use threads to do the same – However, you can elect to do the single server system as minimum requirements

10. Other Requirements (cont) In a real system, the server workstation’s name would be the name of the client stub There would be a client stub for every workstation that it is possible to call upon We are probably going to be forced by resource availability into using only one workstation, but we can simulate a larger system with multiple client and server stubs

11. Other Requirements (cont) You can simulate two or more clients by having two client stubs that are called upon by two programs executing in the background You can simulate two or more servers by having two server background daemon processes – Use different client stub names to select the appropriate server

12. Other Requirements (cont) Don’t forget to kill background processes when you are finished with them !!!