E&CE 454/750-5: Spring 2010 Programming Assignment 1 Due: 11:59 PM Friday 11 th June 2010

Size: px

Start display at page:

Download "E&CE 454/750-5: Spring 2010 Programming Assignment 1 Due: 11:59 PM Friday 11 th June 2010"

Lucinda Stone
5 years ago
Views:

1 E&CE 454/750-5: Spring 2010 Programming Assignment 1 Due: 11:59 PM Friday 11 th June 2010 For this assignment you are required to implement a crude version of Remote Procedure Call (RPC). Normally this would require an IDL compiler to create appropriate server skeletons and client stubs. Given that we do not wish to create such a compiler, we will simplify the interface to four API functions, which will take generic parameters, and it is only a matter of syntactic sugar to clean up appearances. For the RPC implementation, we require three processes: a client, a server, and a binder. You will implement, using TCP/Sockets the client stub, the server stub, and the binder. It is up to the user (i.e. the TA) to write the client and server. To aid you in this, we will provide sample TCP/Socket client/server code. We will also provide some sample client and server test cases. These cases will not be exhaustive, though. You may assume that any function that would normally be performed by an IDL compiler is performed correctly. In particular, this means that the argument type specified in the call will always match the type of the argument that is passed. We will also assume for the sake of convenience that array bounds specified are never incorrect and we never have dangling pointers. All other errors are your responsibility. In particular, you should consider the possibility that various processes are not running, or procedures are invoked before they are registered. The three portions you are responsible for work (briefly) as follows: the client stub must request from the binder the IP address and port number of a server capable of handling the request. It must then marshal the parameters into a message and send the request to the server. It then retrieves the result and returns it to the calling client. The server stub must take registrations from the server and register them with the binder. It must then listen for client requests and, upon receiving such, identify the desired procedure in the server, call it with the appropriate parameters (extracted from the client request), and return the results to the client stub. The binder must take registration requests from the server processes and maintain a database of servers and associated procedures. It must also service location requests from the client processes, either returning IP address and port information for a suitable server or servers, or indicating that no such server exists. Finally, since we may wish to terminate a server or the entire system in a reasonably graceful fashion, the binder and servers should also respond to a terminate request message. If the binder is terminated it should send terminate messages to all associated servers. After that, it will terminate itself. If a server is terminated it is expected to deregister all services from the binder before gracefully shutting itself down. Clients are expected to terminate themselves gracefully without assistance. We will now provide detailed specifications. Client Stub The client will execute a RPC by calling the rpccall function. The signature of this function is: int rpccall(char * name, int * argtypes, void ** args); First, note that the integer returned is the result of executing the rpccall function, not the result of the procedure that the rpccall was executing (which might not be of type integer anyway). That is, if the rpccall failed (e.g. if there was no server that provided the desired procedure), that would be indicated by the integer result. For successful execution, the returned value should be 0. If you wish to indicate a warning, it should be a number greater than 0. A severe error (such as no available server) should be indicated by a number less than 0. The procedure that the rpccall is executing is therefore not able to directly return a value. However, it may do so via some argument. The name argument is the name of the remote procedure to be executed. A procedure of this name must have been registered with the binder. The argtypes array specifies the types of the arguments, and whether the argument is an input to, output from, or input to and output from the server. Each argument has an integer to encode the type information. These will collectively form the argtypes array. Thus argtypes[0] specifies the type information for args[0], etc. The argument type integer will be broken down as follows. The first byte will specify the input/output nature of the argument. Specifically, if the first bit is set then the argument is input to the server. If the second bit is set the argument

2 is output from the server. The remaining 6 bits of this byte are currently undefined and must be set to 0. The next byte contains argument type information. The types are the standard C types, including the null terminated string. const int ARG_CHAR = (1 << 16); const int ARG_INT = (2 << 16); const int ARG_STRING = (3 << 16); In addition, we wish to be able to pass arrays to our remote procedure. The lower two bytes of the argument type integer will specify the length of the array. Arrays are limited to a length of If the array size is 0, the argument is considered to be a scalar, not an array. Note that it is expected that the client programmer will have reserved sufficient space for any output arrays. You may also find useful the definitions const int ARG_INPUT = (1 << 31); const int ARG_OUTPUT = (1 << 30); For example, the type ARG_INPUT ARG_INT 20 represents an array of 20 integers being sent to the server. ARG_INPUT ARG_OUTPUT ARG_CHAR 30 on the other hand is a char array of length 30 sent to and returned from the server. Since we do not know how many arguments there are, the last value we pass in the argtypes array is 0. The args array is an array of pointers to the different arguments. Example: if the client wished to execute result = sum(int vector), the code would be: // result = sum(vector); const int PARAMETER_COUNT = 2; // Number of RPC arguments const int define LENGTH = 23; // Vector length int result = 0; int vector[length]; for (int i = 0; ++i; i < LENGTH) vector[i] = i; int argtypes[parameter_count+1]; void **args = (void **)malloc(parameter_count * sizeof(void *)); argtypes[0] = ARG_OUTPUT ARG_INT << 16; argtypes[1] = ARG_INPUT ARG_INT LENGTH; argtypes[2] = 0; // result // vector // Terminator args[0] = (void *)&result; args[1] = (void *) vector; // Note that vector is the address int ec = rpccall("sum", argtypes, args); if (ec == 0) { // Successful execution printf("sum is %d\n, result); } else { printf("error: %d\n, ec); } To implement the rpccall function you will need to send an information request message to the binder to locate a server of the function. If this results in failure the rpccall should return some negative integer. Otherwise, it should return zero. After a successful information request, you will need to send an execute request message to the server.

3 Note: Multiple servers may implement the same function. If any one server that implements the function is running, the client stub code should successfully call that server. In particular, if two servers implement the function foo and one of those servers is currently busy, or suspended, or crashed, it is not acceptable for the client to fail to invoke the function on the other server. Note: The binder may be busy and/or slow. As such the client must cache the result of prior invocations to the binder, so as to ensure rapid RPC execution in this instance. Server Stub The server wishes to provide services. It must therefore register those services with the binder and then wait for requests which it will service. The signature of the register function is int rpcregister(char *name, int *argtypes, function f); where function is defined as typedef int (*function)(int *, void **); The result returned is 0 for a successful registration, positive for a warning (e.g., this is the same as some previously registered procedure), or negative for failure (e.g., could not locate binder). The first two parameters are the same as those for the rpccall function. The third parameter is the address of the function that is being registered. The binder does not need to know this, but the server stub will need to know it in order to execute it. The rpcexecute function has the signature: int rpcexecute( void ) It returns 0 for termination requested by the binder, and a negative number otherwise (e.g., if there are no registered procedures to serve). During the normal course of operation, this will be the last instruction that the server code writes. It hands over control to the server stub which is expected to call the appropriate procedures as requested by the clients. The server is expected to handle simultaneous requests from different clients. In particular, a very long running request should not block the processing of one that can execute quickly. That said, you do not need to provide for more than two concurrently executing procedures. To implement the register function you will need to send a register message to the binder. Binder The binder accepts information request messages from the client and register request messages from the server. It must therefore maintain a list of procedures that have been registered with it, including arguments, so that when it receives an information request it can respond appropriately. Duplicate signatures must be handled per the requirement for fault-tolerant servers. Thus, a client that requests information about some function must be told all servers that have registered that function. There must be some mechanism for the server and the client to know where the binder is and what port it is listening to. Since this will be dynamic and since we have no control over the /etc/services files, we will use two environment variables. Specifically, the binder must print two distinct lines of the form BINDER_ADDRESS <machine name> BINDER_PORT <port number> where <machine name> is the machine name (fully qualified) where the binder is executing and <port number> is the port number that the binder is listening to. This allows the user at the server or client machine, before executing the server or client, to set these values. The server and client stubs must read these from the environment and call the binder appropriately.

4 Server and System Termination To gracefully terminate a server we must catch the Ctrl-C (SIGINT) signal, and deregister the server s procedures from the binder. Code for catching SIGINT will be provided. To gracefully terminate the entire system a client executes the function: int rpcterminate ( void ); The client stub is expected to pass this request to the binder. The binder in turn will inform the servers, which are all expected to gracefully terminate. Clients are expected to terminate on their own cognizance. Requirements You are required to implement this RPC system as described. You can use any language you like to implement it, but it must link with the client and server stubs as defined in C/C++. In other words, to compile the client I will execute the following command: g++ client.o -lrpc -o client And likewise for the server. Note that the functions must be in a library librpc.a. The user manual is too similar to this specification, and therefore of little value. In addition we will perform testing, so there is little point in doing a test document. However, short of reading your code in detail, determining how you implemented the system is non-trivial. You are therefore required to write a system manual describing how your system is designed and implemented. At a bare minimum it should describe the messaging protocols that you designed. If you don t know what a system manual should look like, imagine that you had to maintain the code that you are writing, but that you did not write the code. Someone else did. What would you need to know about the code in order to maintain it? This is what you should describe. Submission will be via Coursebook. The system is expected to run in the eceunix environment.

5 Arrays, Pointers, and Strings There is a certain amount of confusion as to what the difference is between an array, a string, and a pointer in C/C++. They are not the same thing! An array is a contiguous block of memory, with a known starting address. A pointer is a variable that points to some object in memory. A string is a contiguous block of memory, with a known starting address that is NULL-terminated. Consider the following declaration: char *s1, s2[8], *s3[3]; For s1 the compiler allocates memory for a pointer to a char named s1. For s2 the compiler allocates memory for 8 characters and s2 will be used to refer to the address of the start of that memory. Note that this declaration does not create a pointer to an array it declares only the array. For s3 the compiler allocates an array of pointers to characters (this could be one character or an array of characters depending on how it is used). Assuming the machine we are compiling for uses 4 bytes for a pointer to a char, the memory layout might look something like: 0x s1 0x s2 0x100C s3 0x Assume that we call malloc as shown below and malloc returns the values shown in the comments. s1 = (char *) malloc(8); // returns 0x6000 s3[0] = (char *) malloc(8); // returns 0x6010 s3[1] = (char *) malloc(8); // returns 0x6020 s3[2] = (char *) malloc(8); // returns 0x6030 Now look at the output the following code would produce? printf("0x%x\n", s1); // 0x6000 printf("0x%x\n", &s1); // 0x1000 printf("0x%x\n", s2); // 0x1004!!! printf("0x%x\n", &s2); // 0x1004!!! printf("0x%x\n", &s2[0]); // 0x1004 printf("0x%x\n", &s2[1]); // 0x1005 printf("0x%x\n", (&s2)[0]); // 0x1004 printf("0x%x\n", (&s2)[1]); // 0x100C!!! printf("0x%x\n", &s3[0]); // 0x100C printf("0x%x\n", &s3[1]); // 0x1010 printf("0x%x\n", (&s3)[0]); // 0x100C printf("0x%x\n", (&s3)[1]); // 0x1018!!! Yes, s2 and &s2 have the same value. For (&s2)[1]), the compiler uses the value of &s2 and then adds the size of s2(8 bytes) to that value. For (&s3)[1]), the compiler uses the value of &s3 and then adds the size of s3 (12 bytes) to that value. What you are required to pass for the RPC implementation in the args parameter is a pointer to the argument.

C 1. Recap: Finger Table. CSE 486/586 Distributed Systems Remote Procedure Call. Chord: Node Joins and Leaves. Recall? Socket API

C 1. Recap: Finger Table. CSE 486/586 Distributed Systems Remote Procedure Call. Chord: Node Joins and Leaves. Recall? Socket API Recap: Finger Table Finding a using fingers CSE 486/586 Distributed Systems Remote Procedure Call Steve Ko Computer Sciences and Engineering University at Buffalo N102" 86 + 2 4! N86" 20 +