38984 Remote Communication JRUS) 4.1 Introduction to Remote Communication Distributed applicati i escific applications, nie ne difficult to build with IPC protocols tailored only for aT stributed systems use explicit message passing (send and receive pee ae The programmer handles these primitives and hence, Sian achieve access transparency, which is an essential feature of any istributed system. Hence, it was felt th: i a 3 felt that there was a need for a generalized protocol which would serve the purpose. This chapier i it Call (RPC) and R. . This chapter is concerned with the Remote Procedural (RPC) and Remote Object Invocation (RMI) programming models for distributed applications. RPC is an extension of a local procedural call, which allows client programs to call Server programs running as processes on remote machines. RPC packages the message more like a conventional program and is easy to use. The first half of the chapter focuses on the concepts, implementation, strengths, and weaknesses of RPC. The later part of the chapter discusses RMI. This technique allows objects in different processes running, on different machines to communicate with one another. RMI is an extension of local ‘method invocation, which allows objects in one process to invoke methods of an object in another process running locally or remotely. A later section of the chapter discusses the concepts, features, and operation of RMI followed by an example Java RMI. 4.1.1 Middleware Middleware is a software that provides a programming model one level above the basic building block of processes and also provides message passing, This layer uses protocols such as the request-reply protocol between processes to provide higher-level abstrac- tion, Middleware provides location transparency and independence from the details of communication protocols, operating system, and hardware, RPC and RMI are examples Gfmiddleware, Figure 4-1 shows the role of middleware in remote communication. The following are the various layers of a middleware: Location transparency The client need not know which server process is running its RPC—whether it is local or remote or where it is located. Similarly in > RMI, the object making the invocation need not be aware of the object’s location or whether the object invoked is local or remote. Communication protocols ‘The processes support- ing middleware abstraction are independent of the lower-level transport protocols. Computer hardware RPC uses techniques such as external data representation to hide the heterogeneous jure 4-1. Role of middleware in remot? ature of hardware architecture like byte-ordering communication from the user. Applications RMI, RPC, and events Middlewarebe EET oistributes computing spemidaleware i indepen. on provided bY Operating system The highet ayer abstraction| provi dent of the underlying operating syste «designed usin Use of programming languages Middlewart ieee (DL) guages, such as Java, CORBA, oF Interface De Langu programming lan- model one level above programming Middleware is the software that provides 3 ing. e the best building block of processes and message PIS 4.2 Remote Procedural Call Basi (LPC) model The RPC model is similar to the commonly used Local Procedure Call that is used to transfer data and control within a program. We will first describe the steps involved in LPC execution and then compare it with RPC. In the LPC model, the caller places arguments toa procedure in a specified location—memory or register. Then, the caller transfers the contol to the procedure. The procedure executes in a new environ- ment which consists of arguments given in the calling instruction. After completion, the caller regains control, extracts the results of the procedure, and continues its execution Figure 4-2 shows an LPC execution, Consider a simple LPC Count = read (fd, buf, nbytes) where fd is an integer indicating ° ch es te mas of See an array of characters where data is read, Figure 4-2 indicates the stack before the rameters are pushed onto the stack in the plete, it puts the return value in the call is made from the mai in program. Pa- - hae ale After the read execution is com sister, ves the retum address from the stack, Stack pointer and tran San coo hr aoe Control back to the caller. It rogram’ Mal ‘3 = the parameters D Mein pros han moore worsina singe Bae iom the stack, RPC Bytes ? 4 : ae] 20a Operation fd RPG, thy ea » the caller [ enacts execute on ceo 4nd the server pro- ft me Caller process a Machines, First, the fer Stacy TELS to the server call Message with pa- —_ Cea Pointer es tug es. Then, the caller Before (b) After Lec i SSB Process on ee Waits for a reply Figure 4-2 Local procedure cali atep} , Computes, patver side extracts y Message back the result, and sends caller process.Se As seen in Figure 4-3, an RPC process on the cli- ent machine calls a procedure P(X, Y, Z) on the server at which point the calling process is sus- pended and the server initiates the execution of the called process. When the called process receives the parameters, X, Y, Z, it computes the result *P” and Figure 222° Basic Rec noaei sends a reply message to the calling rocess. Figure 4-4 shows how only one process is active at a time. The client process is in the blocked state Beaman and may do other aeeailieeey Sillotwaiting fr i? ay reply from the server. In RPC, the calling and the Scares Return from called procedures run on different machines and 4 a execute in different address spaces. Message pass- ing carries out information exchange between the Rephy two processes and is transparent to the programmer. (BPC is the popularly used communication mecha- nism for distributed applications because of its sim- ple syntax and semantié3) Figure 4-4 A typical RPC To achieve transparency, designers have made RPC look like LPC, using the concept of stubs that hides the actual RPC implementation from the programs. Both the client and the server processes are associated with stub procedures. RPC implementation mechanism in- volves the following elements: (a) Client (b) Client stub (©) RPC runtime (d) Server stub (e) Server Figure 4-5 depicts the relation between the elements and the steps of a basic RPC operation. An instance of client, client stub, and RPC runtime executes on the client machine, while a similar separate instance executes on the server machine. The caller process is the client and the called process is the server. The following ten steps explain a complete RPC execution process: 1. The client calls a local procedure, the client stub. For the client, it appears as if the client stub is the actual server procedure, which it has called. A stub packages the arguments for the remote procedure by putting them into some standard format and builds one or more network messages. Marshalling is the process of packag- ing the client's arguments into a network message. 2. The client stub sends the network messages to the remote system via a system call to the local kernel. Client Request Calll local procedure and return resultsCET. oiserbutes computing mn. sages to the remote systet 4, The server stub proc unmarshals the arguments ; es @ 5. The server stub execu tion, passing it the argumes 6. When the server procedures ie fers ee ot connection ss ora 3. A connection-oriented ived ‘that it rece seuiolee itsends the: the network me for the client's request | are waits 00 ee FN. jee and converts them from them jocal procedure om the client stub fatto invoke the actual server fin return values to the server stub ——severroutine | RPC runtime machine Figure 4-5 RPC execution 7. The server stub converts the retum Work messages, and sends } marshals them into one or more net them back tothe client stu 8. The messages are transmitted b. 9. The RPC runtime reads the ae mage ack the cet them over tothe client stb, the local kernel and hands 10. The client stub unmarshal Felums ito the client procedy® "S85 converts the return values, and For the clint, it appears tobe g the client. As far as the cient ig Procedure call with t snLPC andnotby gi teed the results returned to hide the actual details of mess , Land-rece A nOle Server is acce ens Ve primitives Ssed by executing antics to provide the call inure SS: LPC and RPC client and the server stub Use the same syntax and se-, eee However, it is difficult to achi : c lieve seme the following differ- ices between RPC and LPC” semantic transparency due to 1g ° Since RPC executes in a different environment and not the caller process’s ma- chine, it accesses the variables and data from the caller program’s address space. Failures, such as node crash, and link failures, are more probable in RPC than in LPC. Hence, a good RPC system should handle these failures * RPC takes a longer time (100-1000 times) to execute than LPC. Hence, RPC should be capable of handling such delays. Based on the above issues, the caller process should have the flexibility of handling failures and delays. 4.2.2 Stub Generation in RPC Both the client and the server stubs perform the important function of hiding the RPC abstraction from the client. One of the methods, manual generation of stubs, is through a set of standard translation functions, whereas another method, auto generation of stubs, is through Interface Definition Language (IDL). It consists of a list of procedure names and supported arguments and results. The programmer writes the RPC interface using IDL. The client imports the interface, while the server program exports the interface. ‘An IDL compiler processes the interface definitions in different languages so that the client and the server can communicate using RPC. The entire RPC compilation cycle is explained in Figure 4-6 Glen 5 program Compiler : Client RPC 5 aS executable interface TDL definition L-Corier Hepders (IDL) Server Serveuetie executable Server Figure 4-6 Steps for RPC compilation In RPC, the caller process and the server process execute on different machines, and transparency is achieved using stubs. RPC consists of the following elements: lient, client stub, RPC runtime, server stub, and server. f . ‘After describing the basic concepts of RPC, we will now discuss the format of RPC mes- sages and how RPCs can be implemented.(ET osrioxces computing ges 4g.t RPC Mess 8 theexecution commences @ request tor @ During an RPC OPE re requestto execute the RPC = Pin the lent BEMET pC and returns the resul de of communication = erected The sever the mo Q@ Return resutt to the client. Based Gh the server, the two types of between the eee 4-7) are as follows: RPC messages BG RPC execu. = 11 messages from the client the server, requesting “ © Request or call mes return the RPC result. sient to # Reply messages in Oe ‘This protocol is independent Dg ee scien woliinamomede messee® = franseed of ie, from one process to another. APC call/request message e ‘The basic function of this message isto request the server tO execute an RPC by provid- its details, such as program, ing relevant details in the message itself. To execute an RPC, version, procedure number, and arguments, are required. The call message has a mcs- sage ID field that specifies the sequence number Iti useful for identifying lost mes- sages or duplicate messages in cae of failure and for matching the reply message to the outstanding messages, if they arrive out of order. The message type field (either | or () specifies call (0) and reply (1) messages. The client ID field allows the server to identify the client before sending the reply I also allows the server process to authenticate the client process before RPC execution. Figure 4-8 shows the RPC request message and its components. ‘ BPC reply message When the client requests the server: ge Fan the BPC, eae eee an RPC, the server receives the call mes- In conditions 1-5, the client receives an a ad ti Te enticed rr -As shown in Figure 4.9, the € are identic ferent for unsuccessful and : » the reply me: ally dif- field bit" the reply these eae replies. In case ie ihe SSage is partially dif 0 zero vessful reply, the status an unsuccessful reply, it is set to one or by the result field, whereas for error. A programmer can specify the RPC RON-2EF0 Value, which speci " f is independent of the trang message feeecines the type ° ! POT Protocols. The dies ee since the RPC mechaniis™ hence responsible for iting the length ae. Be oto, of the Message ‘ pplication designers are Muthin the range specified bY Figure 4-7. RPC messages tion.Remote Communication JIU Gent by client to server for requesting execution So ed of remote procedure Remote procedural call Message | Message| ciient Naentiier] type |identiner| P"09- | Version | roc. | Arg Sequence no. of message for lost and| duplicate messages Allow server to identify client to send reply message. Allow server to check authentication of client process for executing procedure jure 4-8 RPC call/request message format Table 4-1 RPC reply message conditions | fenaton Response from the server j 1. Server receives an unintelligible call 1. Rejects the call. message, probably because the call message has violated the RPC protocol. 2. Server receives the call messages with 2. Return reply unsuccessful and unauthorized client IDs, i.e. the client is does not execute RPC. prevented from making the RPC request. 3. Server does not any receive procedure 1D 3. Return reply unsuccessful and Information from the message ID field— does not execute RPC. program number, version number, or ID. 4, Ifall the above conditions are satisfied, 4. Return reply unsuccessful and the server executes the RPC, but may not does not execute RPC. be able to decode its arguments due to incompatible RPC interface. 5, Server executes the RPC, but an exception | 5. Return reply unsuccessful. condition occurs. 6. Server executes the RPC successfully 6. RPC is successful and the server without any problems. Feurns the result, providing its relevant details in the message itself. The RPC reply message consists Oo ‘An RPC call/request message is sent by the clientto the server to execute an RPC by of the result or an error code, based on the execution of the RPC by the server.Los § Distributed Computing Error conditions a Tr - 11 message not intelligible Message [Message] REP enor) + (we protocol violated) Wdentifier | type | Status | condition} - fea. Sesines 2, Unauthorized to use servi Server finds the remote program, - SEE procecure numbers are ; riot available with it 7 4, Unable to decode supplied Message |Message| Reply | Result | arguments A identifier | type ful | 2} 5. During execution, an exception Ther Remote procedure executed condition occurs diffi ‘successfully take Figure 4-9 RPC reply message format } Ee folle 4.3.2 Parameter Passing Semantics The function of the client stub is to take parameters from the process, pack them into a message, and send it to the server stub, The choice of a suitable parameter passing: 4 1 semantic is crucial to design an RPC mechanism. The various parameter passing seman. the tics are call-by-value, call-by-reference, and call-by-copy/restore semantics. We discuss ( fist each of these semantics in this section. | Hi ple DAll-by-value semantic to th This semantic copies all the parameters into a message before transmitting them across 7 the network. It works well for compact data types, such as integer, character, and arrays. para The process ofpacking the parameters into a message is termed as marshalling. To make not an RPC, the client sends the arguments. and the server returns the result, The parameters chai arguments/results are language-dependent data structures, transferred in the form of & message. As explained inthe earlier chapter, the message-passing Fees involves Client i - Marshalling is a similar process carried out during RPC execution. The marshaling process consists ofthe following steps: | * Identify the message data—arguments in the ef : result to the remote process. client or server process transmit the ¢ Encode the data on the sender’s machine a me .. stream form and placing them in amewsoge anette program object infos © On the receiving machine, ae decode 2 program objects, = message, i.e., convert the message into Client {eventos and 7 tagged representation method is Used. The mart nn aun of results, tagged or un- program objects—structred and user-defined detatyaer oes US Feet all types of)sce TED There are two classes of marshalling procedures: © The first group consists of procedures for scalar data types and those compound data types that are built from the scalar message. These are a part of the RPC soft- ware. * The second group contains marshalling procedures defined by the RPC system users for user-defined data types and those which include pointers. A good RPC system should generate its own marshalling code for every RPC. Therefore, the programmer will be relieved from doing this task. Practically, this is difficult because a vast amount of code is generated to cater to all data types. Let us take an example of a simple procedure ‘add’, which is remotely executed. As shown in Figure 4-10, the add procedure is executed in the client process. The client stub puts the following values in the message: ¢ Two parameters for execution # Name or number of the procedure called in the message The server stub receives the message, examines it, and makes the appropriate call. If the server supports other remote procedures, the server stub switches between multiple procedures. The actual call looks like a local call except that the parameters extracted from the message are sent by the client. After the server completes execution of the mul- tiple RPCs, the server stub takes control. It packs the result into a message and sends it to the client stub, which unpacks it and returns the result to the client process. The RPC model works well if the client and the server machines are identical and the parameters and results are scalar types, such as integers, characters, or Boolean. This may not hold true in a large distributed system. For example, IBM mainframes use EBCDIC character code, whereas IBM PCs use ASCII code. Similarly, Intel Pentium machines use Server machine Client machine 1, Client call to Server process ere procedure Implementation || | 6. stub makes of add faa Serveriatub: local call to ‘add’ k= addi} Glient stub k = add(i,j) proc:iadd: 2. Stub builds proci‘add” iletib Unpecke [_ int: val(i) message int: val()) ‘ tile int: vall int: vai(j) | prociadd” int: val( 4, Server OS a8 int: val(j) seen 06. hands message to server stub 3. Message is sent across the network Figure 4-10 Example of call-by-value semanticjan’ format, whereas Sun SPARC machin, Set siormin Figure 4.1, ee miinication, tessa, 88 are a eae byte. Unequal byte-ordered mq. tranafered a the data in reverse order. Hen, eens sysiem with these types of machines a by the client. Suppose th, ane ee ae pe a ety It Coe the et of call-by-value more clear. The integer value of fd and nbytes are passed by value an the caller-side values are unaffected. Call-by-value semantic is required because the client and the server exist par different address spaces and may be running on different types of machines. It is ideal for closeg Systems, where the client and the server share a single address space. However, this Semantic is unsuitable for transmitting large voluminous data, such as multidimensional array, trees, etc., where part of the data may not be Fequired on the server side for RPC sxecution. The call-by-reference semantic is used to transmit this type of data, Call-by-reference semantic Uttle-endian 15 | 16-23 Big-endian [2a-3i feos Figure 4-11 Data repvesentations the aray. The caller process can modify the elements of the fice «array and these changes happen in the array whose value was passed by Call-by-copy/restore semantic Call-by reste semantic j par for isapseaty ae of eee tate Semantic, but it uses the stack These Vatables are accessible tp the Sltent copies the variables to the stack and overwrites the client's origi i Performs the RPC execution for getting the RPC execuion ena inthe stack. Now the client accesses the stack arbitrary linked data , such, oe Pyitestore is not often used to handle Feeursive structures such as s hash tables, or even non- “customer? opi? ‘company’ objets. This i became gcy dan pointes Separate ‘address’ and Se Mtuctres may take up 4 large amount of Which parameter passing semany Semantic Based on th prope ofthe bone Pe? Language designers decide the Edee +11] NS eee ace ener ol smeela beeen es Call-by- reference passes pointers to the parameters that are passed from the client to the server, and call-by-copy/restore uses temporary storage which is accessed by both the client and the server. 4.3.3 Server Management In RPC-based applications, there are two important issues that need to be considered for server management, namely server implementation and server creation semantics. We discuss both of them in this section. Server implementation We classify the servers as stateless and stateful, based on how they are implemented. A stateless server, as the name suggests, does not maintain the state information of RPC execution in the system. Hence, they include parameters for a successful operation in ev- ery request made by the client. On the other hand, ina stateful server, if the client makes multiple calls, the state information for all the calls is maintained by the server process Subsequent calls execute with the help of earlier state information. A stateful server is easy to restart on failure. This type of server relieves the client from maintaining the state information. In the event of a failure, if the stateful server crashes and restarts, all the earlier state information is lost. The client, being unaware of this problem, will produce inconsistent results. Similarly, if the client crashes, the server may keep on holding unwanted state information. However, stateless servers have a distinct advantage in case of failures, because the client keeps retrying until the server responds. Hence, stateless servers make crash recovery easy. Server creation semantics During an RPC call, the client and the server processes execute independently, i., they run on separate machines, which have separate address spaces and lifetimes. Therefore, the middleware creates and installs the server process earlier or creates it on demand. Depending on the time duration for which a server is active, servers are classified into instance-per-call, instance-per-session, and persistent servers. Instance-per-call server After RPC execution, the middleware destroys the instance -per-call server. They are stateless servers. The client process or the operating system maintains the state information. This approach is expensive in a distributed application, if the same server has to be invoked multiple times. It involves the overhead of resource- buffer space allocation and de-allocation. Instance-per-session server Here the instance is maintained such that multiple RPC calls ‘can be executed by the same client. There is a server manager for each type of service. All server managers register with the binding agent. To execute an RPC, the client contacts the binding agent specifying the type of service needed. The client gets the corresponding, ts the server manager With a rey. server manager addres. Then, the client COMBS TTT ire cession Wy create a server. The client and the server interact sears the server is destroy; 5° client informs the server that the RPC session alyasingleclien. server can retain information between calls, but it serves Om'y P Persistent server This type of server exists indefinitely a ae aMOng the ‘ ii sti e clients inthe distributed system. A peristnt seven is fea And istaled by client uses it. Each server exports the services and registers i ae a NB ARCH. The client contacts the binding agent with a request for service. The binding agent selec... locates the server and retums the address of the selected server to the client. \ client interacts directly with the server. This type of server is bound to multiple simultaneously, servicing interleaved requests. MAEM istrinutea computing | recovery in event ofa crash) and stateless (does not maintain state informat, ‘Depending on the time duration for which a server is active, servers are class + oO Servers canbe dassified into stateful (maintains all information and assists in « into instance-per-call, instance-per-session, or persistent servers. RPC Communication and client-server binding in RPC. 4.4.1 RPC Call Semantics called node can fail independent! tion link may fail ede ily and may restart late. Additionally, the communica- a the called and the caller node. The RPC execution is disturbed, leading : aller or called node crashes, Tae eee ll Ot esponse message and ‘he failure handling code, ‘ | The call semantics define how ofenarem, tions. These are as shown in Figure 4-12 mole Procedure is executed under fault cons! Tuntime system should have an intc2tl Exec once cal