For this project, you will implement a simplified RPC run-time system, along with client and server side stub routines for a set of functions provided to you, and a set of functions/programs that you design to demonstrate that your system works properly. The system should support function versioning, a choice of at-most-once and at-least-once semantics, and a dynamic binding process realized by a binder that exists at a well-known address within the system. Your implementation does NOT have to include a front-end mechanism for generating client side and server side stubs automatically. However, the design and organization of your software should reflect the fact that real-world RPC systems are used that way, and should be designed so that a front-end stub generator could be conveniently added to your solution. Your implementation also does not have to deal with matters of data conversion. All processes in the system will run on the Sun machines in the South Pod Laboratory on the first floor of the Engineering building. Your system should allow parameters and return values of type int, float, or char, along with arrays of these types consisting of up to 1024 elements. You do not have to handle any other types (e.g. double, short, etc.), nor records (structs) or pointers. At the time of registering an RPC function with the binder, the server should somehow indicate the call semantics of the function; that is, the server should say whether the semantics are "at-most-once" or "at-least-once". This call semantics should be returned to the client when it binds to the server, and should be reflected in calls to that function. Your RPC system should be built on top of Unix sockets, using C (or C++). You may want to use a threads package as well. As mentioned, you should implement a binder that runs at a well-known address, but this address (IP / port number pair) should be somehow configurable at run-time... (either by having it be read from a file by the server, client, and binder itself, or by including it as a command line argument, etc.---this will make things much easier on you during testing.) Make sure your binder and servers can deal with multiple simultaneous requests from clients. Grading You will be graded according to the following criteria: (1) [40%] Does it work?: Does your solution implement the basic functionality required. We will provide a test case for you to play with shortly (as soon as the TA gets back in town!)
Complete and fully-functional working program(s) in executable form as well as complete source code of all work done. Complete copyrights to all work purchased. code, with lots of documentation, clear comments, executable, separate c files for client.c , server.c and binder.c , header functions for serverstub.h, clientstub.h, etc.
Unix/sun solaris C code only