RPC’s hide the intricacies of the network by using a ordinary procedure call mechanism familiar to every programmer. A client process calls ...
RPC’s hide the intricacies of the network by using a ordinary procedure call mechanism familiar to every programmer. A client process calls a function on a remote server and suspends itself until it gets back the results. Parameters are passed like in any ordinary procedure. The process that issue the call waits until it gets the results. The RPC run time software collects the values for the parameters, forms a message and sends it to the server . The server receives the requests, unpacks the parameters, calls the procedure and sends the reply back to the client.
Here are some of the issues faced by RPC:
1. How are the server functions located and started ?
An entire run time environment is required to start and stop servers, prioritize requests, perform security checks and provide some form of load balancing. Threads are much better at handling these incoming requests than full-blown process. It is better to create a server loop that manages a pool of threads waiting for work rather than create a thread for each incoming request. The real need on the server is TP Monitor.
2.How are Parameters defined and passed between the client and the server ?
The better NOS provide an Interface Definition Language (IDL) for describing the functions and parameters that a server exports to its clients. An IDL compiler takes these descriptions and produces source code stubs for both the client and the server. These stubs can then be linked with the client and server code. The client stub packages the parameters in an RPC packet, converts the data, calls the RPC run time library and waits for server’s reply. On the server side, the server stub unpacks the parameters, calls the remote procedure, packages the results and sends the reply to the client.
Here are some of the issues faced by RPC:
1. How are the server functions located and started ?
An entire run time environment is required to start and stop servers, prioritize requests, perform security checks and provide some form of load balancing. Threads are much better at handling these incoming requests than full-blown process. It is better to create a server loop that manages a pool of threads waiting for work rather than create a thread for each incoming request. The real need on the server is TP Monitor.
2.How are Parameters defined and passed between the client and the server ?
The better NOS provide an Interface Definition Language (IDL) for describing the functions and parameters that a server exports to its clients. An IDL compiler takes these descriptions and produces source code stubs for both the client and the server. These stubs can then be linked with the client and server code. The client stub packages the parameters in an RPC packet, converts the data, calls the RPC run time library and waits for server’s reply. On the server side, the server stub unpacks the parameters, calls the remote procedure, packages the results and sends the reply to the client.
3. How are failures handled ?
Because both sides of an RPC fail separately it is important for the software to be able to handle all the possible failure combinations. If the server does not respond, the client side will normally block, time out and retry the call. The server side must guarantee only once semantics to make sure that a duplicate request is not re executed. If the client unexpectedly dies after issuing a request, the server must be able to undo the effects of the transaction. Most NOSs provide the connectionless and connection oriented services.
4. How is security handled by the RPC ?
Modern NOS like DCE make it easy to automatically incorporate their security features into RPC. User need to specify the level of security required then the RPC and security feature will cooperate to make it to happen.
5. How does the client find its server ?
The association of a client with a server is called binding. The binding information may be hardcoded in the client or client can find its server by consulting a configuration file or an environment parameter. A client can also find its server at run time through the Network Directory Services. The process of using the directory to find a server at runtime is called dynamic binding. The easiest way to find a server is let the RPC do that in which case it is called automatic binding.
6. How is data representation across systems handled?
The problem here is that CPUs represent data structures differently. To maintain machine independence, the RPC must provide some level of data format translation across the systems. For example the Sun RPC requires that clients convert their data into a neutral canonical format using the External Data Representation APIs. In contrast DCE’s Network Data Representation service is multicanonical meaning that it supports multiple data format representations. The client chooses one of the formats tags the data with the chosen format and then leaves it up to the server to transform the data into a format it understands. In other words Server makes it right
