/**********************************************************************/ /* Note : A very short introduction on RPC. */ /* By : Albert van der Sel */ /* Version: 1 */ /* Date : 11/06/2009 */ /**********************************************************************/ This very short note, introduces the concept of RPC (Remote Procedure Call). =========================== Section 1. RPC: What is it? =========================== RPC lets you write programs, that may call procedures from other programs on different computers. (If your program would call a procedure from a local program (on the same machine), you would use a "local procedure call"). We say "procedure", but what about 'methods' or 'memberfunctions' from (oo like) objects? Should we then call it "Remote Method Invocation" (RMI), or something like that? Indeed there is already a mechanism named "RMI" in the java world. But the mechanics of RMI is somewhat different from RPC, although in many respects they are quite similar. (A seperate short note on RMI can be found on the "Java links" page, of this site.) Let's try to list a few characteristics of RPC: - RPC is quite "old". So, at that time, programming was mainly done with procedural languages like C. Therefore, writing procedures was the "thing to go for". Hence the name RPC is thus quite obvious. Even if the basic idea is quite old, the protocol has evolved, and is still heavily used at many Client/Server systems, and other distributed systems. Here you might think of many business-like programs (like for example financial transaction systems). Yes, but even many "stuff" we all take for granted on the OS level, uses RPC. Think of authentication services with a client and server part, or some types of file- and print services, or network filesystems (nfs) etc.. - RPC is an IPC (Inter Process Communication) implementation. It's a way to let remote processes communicate. Especially here, it is understood that the client wants a remote Server process to do some work, and typically return values to the client. RPC is a high level protocol, that usually "sits" above "sockets", and below the sockets functionality, ofcourse, the transport layer and the network layer are in place (which usually is TCP IP). But, instead of the sockets interface, other communication facilities might be used, like "named pipes". And even "Transport Independent" (TI) RPC might be used, and that usually might need special libararies at the client and Server. But as said, socket based RPC is widely in use, and the following figure tries to show that. --------- | RPC | --------- |sockets| (portnumbers / registering portnumbers) --------- |TCP/UDP| --------- | IP | --------- - Synchroneous and Asynchroneous RPC. The traditional RPC model was synchroneous, which means that the client calls the remote procedure, and "waits" for the result to return. In many articles, that mechanism is depicted as in the following picture. | | |call | ------------>| response | <------------| | | | | Client Server The vertical lines then, are supposed to depict the "activity" of the process. Ofcourse, a number of obvious drawbacks can be seen on this model. For one, the client must wait for the Server to give the response. Asynchronous RPC, separates a remote procedure call from its return value, which resolves a number of limitations of traditional, synchronous RPC - Stubs, marshalling: The client and Server processes, might reside on very different platforms, and Operating Systems. Furthermore, the client and Server might even be programmed with completely different compilers. So, for example, what the Server process expects to get in terms of data representations, formats, and parameters, might be very different from what the client thinks is right. So, at the location of the client and Server, socalled "stubs" has to be present, along with some other rpc runtime libraries, which which will do the neccessary marshalling. Now let us try to make a simplistic figure, that gives an idea on how RPC works: -------- ---------- |Client| <------- |Server | -------- -------> ---------- | | ------------- ------------- |Client Stub| |Server Stub| ------------- ------------- | | ------------- ------------- |RPC Runtime| |RPC Runtime| |Library | |Library | ------------- ------------- | network | ---------------------------------------- - Locating the services: How does the client "find" the machine and Server process, that is supposed to run a certain procedure? You can imaging, that the client wants to know: Hostname (ip address) program identifier procedure identifier Well, to find a machine, there are several ways to do that. And it must certainly be so, that RPC includes support for looking up the portnumber of a remote program. So portmappers (or other modules with some name, but with the same function) must be present on any machine running RPC Servers. A RPC Server will register itself on which ports they listen, for providing services. That's it. But I told you so: it's short !