Sun’s Remote Procedure Call

1. Sun’s Remote Procedure Call • Part of Open Network Computing Architecture • Remote Procedure Call (RPC) • Preserve call/return semantics in a distributed system • Try to achieve access transparency • Support ‘interface’ semantics • External Data Representation (XDR) • Try to achieve portable information and data models • Mappings to/from Network-Virtual-Machine • PortMapper • Try to achieve location transparency

2. Logically One or more components ‘remoted’ Implements interface say int sum(int x, int y)

3. Engineering - Caller New module on caller-side (client) Preserves ‘local’ interface int sum(int x, int y) Acts as proxy for ‘real’ remoted interface Implements ‘access transparency’ Must communicate with remoted

4. Engineering – Callee Skeleton Provides support For remoted component Server Skeleton sum virtual real Host supports skeletons

5. Engineering • Proxy makes it appear remoted component is still present • Proxy implements same interface as remoted component • Proxy has to find out where remoted component is and send messages to/from it • Each remote host (hosting server) has to provide a host:port endpoint to support communication with each remoted component/interface. • Skeleton has to talk to host to get messages and convert these into calls on the interface of the remoted component • Only the proxy and skeleton need to know the interface details

6. Engineering - Support • How does the proxy know where the remoted component is? • The PortMapper • Acts as a telephone exchange and directory services • For each host on which it runs as a service maintains a list of (host:port)<->interface names mappings • Caller broadcasts “who is hosting interface ‘a’” • Portmapper on host responds “me on port 2345” • What if two developers use same interface names? • Sun provides global GUID for each interface • Your interface ‘a’ is ‘X001fea1234’ • My interface ‘a’ is ‘X157a000ei6’

7. Engineering - Support • What if remoted component contains implementations of multiple interfaces? • By extension, deployable unit is the component (named) and each component has several interfaces. • Caller proxy and Callee skeleton need to identify which interface in which component. • Host needs only map named component to host:port for skeleton to get right messages. • Task • Take (main, sum, diff) and map it onto Sun RPC • Walk through deployment and a call to sum and diff.

8. /* date.x - Specification of remote date and time service. */ /* * Define 2 procedures: * bin_date_1() returns the binary time and date (no arguments). * str_date_1() takes a binary time and returns a human-readable string. */ program DATE_PROG { version DATE_VERS { long BIN_DATE(void) = 1; /* procedure number = 1 */ string STR_DATE(long) = 2; /* procedure number = 2 */ } = 1; /* version number = 1 */ } = 0x31234567; /* program number = 0x31234567 */ /* 0x20000000 - 0x3fffffff for users*/ /* Note the mapping of the program to a "Hopefully" unique ID, the global program number Within this program are two functions/procedures identified again by number Bin_Date is (remote) procedure 1 Str_Date is (remote) procedure 2 Therefore the *.x file contains a program name to unique ID mapping and also maps by extension the procedures. The portmapper process running in Unix takes the above and maps it toa network 'port', thereby achieving a service name to ID to network end-address mapping. */

9. Computer A Computer B ClientProcess ServerProcess ··· Main() { ···· RemoteProcX(…) {/*execution code*/return result; } RemoteProcX(x,y,z, result) ··· ··· 6.Result Client stub Server stub 10.Unmarshall Result parameters 1.Determine address of server process2.Marshall call parameters x,y,z,result 5.Unmarshall call parameters x,y,z and result 7.Marshall result RPC transport RPC transport 9.Receive message 3.Send message 4.Receive message 8.Send message

10. Information and Data Model • Marshalling • Taking actual parameters specified in the interface and mapping these onto a message body along with the interface and component names • UnMarshalling • Taking the message body and performing reverse of the above • Sometimes called serialisation/deserialisation

11. External Data Representation - XDR • How do we make the parameter list, message structure and encodings portable across all platforms? • Parameter list -> adherence to interface specification • Structure and Encodings -> adherence to a type-system on a network (virtual) machine architecture • XDR on NVM • Proxy does host-to-net (hton) on ‘call’ and net-to-host (ntoh) on ‘return’. Skeleton does reverse. • Each host has ‘ntoh’ and ‘hton’ libraries to map types • Task • Work through (int) y = (int) a ((int) x = 2, (int) z = 3) where caller has 2-byte integers, NVM has 4-byte, and callee has 8-byte

12. ‘x’ int 8 bytes RtoL ‘3’ ‘x’ int 2 bytes LtoR ‘3’ in in in in ‘y’ int 2 bytes LtoR ‘2’ ‘y’ int 8 bytes RtoL ‘2’ out out ‘z’ int 8 bytes RtoL ‘5’ ‘z’ int 2 bytes LtoR ‘?’ XDR • The job of proxy is to convert from local representation to abstract machine representation. • It takes native (given) entities and converts to target architecture. • Procedure call z = sum(x,y) • Proxy constructs a table hton Msg bits Msg bits ntoh

13. XDR • Shortcomings • Few supported types in NVM • ‘Optimised’ for Sun • Need for libraries to be kept consistent • Not easily scalable • Solution? • See later – Java and XML/ASN

14. RPC Model • The Remote Procedure Call • Map call/return to communication model • Need local deflectors • Need ‘name’ to unique network identifier mapping • Need parameter to information/data mappings • Need ‘in’ and ‘out’ semantics

15. RPC Model • Automation of RPC • Map names to identifiers • bind through unique ports or ‘case’ switch • For each ‘in’ parameter, caller does host-to network map • For each ‘out’ parameter, caller does network-to-host map • Called routines reverse above

16. RPC Mapping • This description, in general, for a given module lists:- • all callable routines and means of unique identification • all ‘in’ and ‘out’ parameters • defines ‘public’ interface • the Interface Description File • an Interface Description Language • associated with particular language and platform bindings (rpcgen/Unix; Java/Corba)

17. Production Process IDF client logic proxy skeleton service logic design build auto client service

18. IDF and IDL • Interface • defining the distribution • specify the functions and information flows which characterise the component parts into which the system is partitioned • depends on framework for distribution (RPC, DCE, CORBA..) but not language(s) of implementation • IDL compiler down to language level (rpcgen, idl2java,..) for implementation • data and encodings still be be fixed

19. Distributed Computing Environment (OSF/DCE) The DCE IDL Compiler The DCE IDL compiler idl processes interface definitions written in IDL and generates header files and stub object code. The code generated from an interface definition by the compiler includes client and server stubs. The compiler also generates a data structure called the interface specification, which contains identifying and descriptive information about the compiled interface, and creates a companion global variable, the interface handle, which is a reference to the interface specification. Each header file generated by the IDL compiler contains the reference the application code needs to access the interface handle. The interface handle allows the application code to refer to the interface specification in calls to the RPC runtime. Runtime operations obtain required information about the interface, such as its UUID and version numbers, directly from the interface specification.

20. /* bank.idl */ interface bank{ typedef [string, ptr] char *acct-t /* define a data type for the account name - assume 10 characters */ void deposit{ [in] acct_t acct, /* in account parameter */ [in] unsigned32 amount, /* 32-bit unsigned integer */ [out] float balance /* floating point number assume 64-bit */ }; void withdrawal{ [in] acct_t acct, /* in account parameter */ [in] unsigned32 amount, /* 32-bit unsigned integer */ [out]float balance /* floating point number assume 64-bit */ }; } Simple Banking Example

21. The Microsoft IDL Compiler - MIDL The MIDL compiler processes an IDL file and an optional application configuration file (ACF) to generate a set of output files. The compiler can generate source files for an RPC interface or for a custom OLE interface. By default the compiler generates the following files for an RPC interface: ·Client stub (name_c.c) ·Server stub (name_s.c) ·Header file (name.h) When the object attribute appears in the interface attribute list, the compiler generates the following files for a COM interface: ·Interface proxy file (name_p.c) ·Interface header file (name.h) ·Interface UUID file (name_I.c) When the local attribute appears in the interface attribute list, the compiler generates only the interface header file, Name.h.

22. RPC • IDF and IDL – good logical separation of architecture and data • XDR tried to facilitate information model and data model • XDR has been overtaken by modern architectures • Java • Instead of distributing libraries we distribute JVM • Review roles of ‘client’ and ‘server’ • Need for the client to get attached not just to one particular component but to a component that provides required service, therefore the need for replication (Sun RPC does not allow that). • Registry • Java and CORBA have very strong registration

23. Generic Model API Middleware Application Web Services COM/ DCOM RMI Corba RPC Transport Network Programming