Chapter 5

1. Chapter 5 Middleware

2. Topics • Server structures • External data representation • Remote procedure call (RPC) • Interface definition language (IDL) • Java RMI • Java security • Failures and service guarantees • Stateless and stateful servers • Naming and name look-up service (DNS)

3. RPC & RMI

4. Layered Communication Architecture

5. Server Structures

6. Server Components

7. Examples • Ex1: Disk server • Listener and one worker. After servicing current request, worker checks list. • Ex2: Window server • X Window server manages several windows: issues select to constantly watch events on keyboard and mouse. If, e.g., right_mouse_button_down is detected, it creates worker thread, which pops up appropriate menu and executes selected command.

8. Web Server Web server process Worker threads Dispatcher thread User space Web page cache Hard Disk Network kernel • Dispatcher thread: reads incoming requests • Worker threads: downloads requested pages

9. All threads in the same process share same resources Thread 2: reformatting Thread 1: Update page 1 Listen to keyboard Go to page 600 Thread 3: Backup Kernel Spreadsheet

10. Produce-Consumer Relation • Listener is producer • Workers are consumers • If the request list is empty, worker thread calls method wait( ) in monitor on condition list_nonempty • When listener places new request, it invokes notify( ), which wakes up waiting worker thread, if any. • Other ways for mutual exclusion/synchronization?

11. UNIX inetd Daemon (listener) • Invoked at boot time • Consulting /etc/inetd.conf file, creates one socket for each service and binds port number. • Invokes select on socket descriptors • select ( …, *readfds, *writefds, …, *timeout) • readfds points to bit pattern of file descriptors (“1” if fd is of interest). • Upon return, bit pattern indicates fd’s which are ready for input. • inetd invokes accept on active descriptors and forks worker thread to serve request; • Go back to select.

12. /etc/inetd.conf

13. Design Options • Single-threaded server (for simple services) • Listener and one thread per request • Upon receiving request, listener spawns worker. • Upon completion worker dies. • No contention for shared queue • Thread creation/destruction overhead • Listener and fixed number of worker threads • Each worker thread checks request buffer and services request. Idles if no request. • Limited concurrency • Real-life example: SQL Server 2000

14. local C remote E local invocation invocation remote invocation invocation F B local A invocation D Remote Procedure Calls • Purpose: call the procedures that are locally unavailable. • Any other way(s)?

15. RPC Flow

16. Invocation Semantics • Maybe: the invoker cannot tell whether a remote method has been executed once or not al all. • Supported by CORBA • At-least-once: re-transmission of request until reply arrives. • Require idempotent operation • Supported by Sun RPC • At-most-once: the invoker receives either a result or an exception. • Require more fault-tolerance measures • Supported by Java RMI and CORBA

17. Sun RPC Message Format • Uses UDP • Other UNIX versions use TCP • At-least-once call semantics • XDR • Request • xid (unique tag) • prog (100003 for NFS protocol) • vers (version no.: 2, 3 or 4 for NFS) • proc (procedure no.; see Fig. 5.8 of Text) • Authentication info (client machine name, userID, etc.) • Arguments for procedure • …. • Restrictions • Not support interface name • Single input parameter • Not scale well

18. RPC Components • Interface defined in Interface Definition Language (IDL) • Client stub and server stub (also called skeleton) make remote calls transparent, i.e., hide communication from users. • Stub generator (or ID compiler) generates stubs by compiling interface definition. • Issues to be considered • Binding • Security

19. IDL • No existing language has all types in all other languages • C cannot be IDL: char* in C cannot be translated uniquely to pointer to character, or pointer to array of characters. • New I/O types, in, out, inout, are useful in IDL. • CORBA, Sun XDR, DCOM, DCE, MiG (subset of Matchmaker), Courier, have their own IDLs. • Java can function as IDL for Java programs • CORBA allows client and server programs to be written in different languages.

20. IDL Example (Sun XDR) const MAX = 1000; typedef int FileIdentifier; typedef int FilePointer; typedef int Length; struct Data { int length; char buffer[MAX]; }; struct writeargs { FileIdentifier f; FilePointer position; Data data; }; struct readargs { FileIdentifier f; FilePointer position; Length length; }; program FILEREADWRITE { version VERSION { void WRITE(writeargs)=1; 1 Data READ(readargs)=2; 2 }=2; } = 9999;

21. Stubs • Marshalling (serializing or flattening) and unmarshalling (de-serializing) • Also required for persistent object stores • Data format conversion between heterogeneous systems (Big endian, little endian, ASCII, EBCDIC, etc.) • In Sun, converted to XDR. • Two ways to do data conversion

22. Client Stub • Marshall procedure id and parameters. • Send message to server and wait by blocking receive. • Unmarshall returned result • Deliver it to calling process.

23. Server Stub (Skeleton) • Unmarshall message and extracts procedure id and parameters • Security checking • Invoke called procedure using standard procedure call • logging • Compose reply message (marshalling) • Send it back to client

24. Stub Generator (Compiler) • Stub generator generates stubs by compiling interface definition. E.g.,rmic (Java), rpcgen (SunOS), MiG (Mach), uuigen (OSF DCE). • Generated stubs are linked to client and server programs • Server and client stubs could be in different languages. • Only interfaces are included in stubs.

25. rpcgen

26. Locating Server • Sun RPC uses portmapper at well-known port (111) on each computer • It lists program#, version#, and port# used by each local service • On start up, server registers with local portmapper, providing this info. • Client sends prog# and version# to remote portmapper to find server port • Q: why don’t specify the port number in the interface?

27. Server Port Lookup 1: register program, version, and port; 2: look up port number; 3: port# returned; 4: request/reply Q: How to broadcast messages to multiple instances of a service on different machines?

28. Portmapper Interface Definition program PMAP_PROG { version PMAP_VERS { void PMAPPROC_NULL(void) = 0; bool PMAPPROC_SET(mapping) = 1; int PMAPPROC_GETPORT(mapping)= 3; } = 2; } = 100000;

29. Authentication • Needed for request and reply • UNIX style: uid, gid • Digital signature • Kerberos style • Widely used in intranet (campus, company) • The default authentication service in Windows 2000

30. General Service Lookup

31. Steps for RPC • Define the RPC Interface in a .x file. • Use rpcgen to compile the .x file • Code the server implementation • Build and run the server • Write a client

32. Step 1: Define the RPC Interface in MyRPCService.x file struct aTypeStruct { int i; double d; }; typedef struct aTypeStruct aType; program MyRPCService { version ThisVersion { aType function_foo(int) = 1; int function_bar(aType) =2; }=1; }=34567;

33. Step 2: Use rpcgen to compile the MyRPCService.x file • % rpcgen MyRPCService.x • MyRPCService.h --- the common header file for the RPC, read the generated comments. • MyRPCService_xdr.c --- the XDR routine for struct aType. This file will be used by both the client and the server. • MyRPCService_cln.c --- The generated client stub. An RPC client application calls the functions defined in this file. • MyRPCService_svc.c --- The generated server stub. • MyRPCService_imp.tmp.c --- The server implementation template, you copy this file and fill in the server implementation. • MyRPCService.hpp ---- The C++ class for the client • MyRPCService.mak ---- Makefile, you need to edit this

34. Step 3: Code the server implementation • the RPC server programmer must implement the functions defined in MyRPCService.x file to do the real work. • rpcgen generates a server implementation template file, you can copy it over and fill in the details.

35. Step 4: Build and run the server • Compile the MyRPCService_xdr.c, MyRPCService_svc.c and MyRPCService_imp.c files • Link with the pwrpc32.lib library to build executable file • Start the portmapper if necessary • Start the server we just built

36. Step 5: Write a client (simplified version) int i; aType a, *ap; CLIENT * cl = clnt_create ("server_host_name", program_number, version_number, "tcp"); ap = function_foo_1(&i, cl); i = function_bar_1(&a, cl);

37. Summary of RPC • Widely used before. Now HTTP plays the major role. • Strict request-reply paradigm • Not good for certain relational database applications • Complexity of server • Responsible for almost all stuff: security, logging, service • Difficult to implement complex service

38. remote object Data remote interface m4 { m1 implementation m5 m2 m6 of methods m3 Java RMI • Don’t need a special IDL • Must extend the java.rmi.Remote interface

39. Java RMI Example import java.rmi.* ……. public interface Find extends Remote { public String findLine ( String keyword ) throws RemoteException; }

40. Server Implementation public class FindImpl extends UnicastRemoteObject implements Find { public FindImpl ( String aFile ) throws RemoteException { } //end constructor public String findLine ( String keyword ) { This method finds if keyword is in aFile } //end method public static void main ( String args[ ]) { try { System.setSecurityManager ( new RMISecurityManager () ); FindImpl server = new FindImpl(aFile); Naming.rebind(“127.0.0.1:2099/FindServer”, server); …..} catch {……..} } //end method } //end class

41. Java Registry Overview

42. Stub Generator • rmic • Generate both server and client stubs • Move server stub to the codebase • Move client stub to the client machine • Required for compilation.

43. Service Lookup And Sending Request by Client public class FindClient { public static void main (String args[] ) { …… String name = “rmi://” + “hostName:2099” + “/FindService”; Find obj = ( Find ) Naming.Lookup (name); String results = obj.findLine ( args[0] ); …… } }

44. Compiling and Running

45. RemoteObject RemoteServer UnicastRemoteObject Activatable <servant class> Classes Supporting Java RMI

46. Java Security • In Java, executable contents can be shipped to other hosts and executed, e.g., applets. • Implication? • A new problem?

47. Degree of Trust • The base classes • i.e., Java’s built-in classes, e.g., java.lang.* • Local classes (on CLASSPATH) • Remote classes (remote for the standpoint of the client) • e.g., applets • Trusted classes: base and local • Untrusted class: remote

48. Default Restrictions on Applets • Run in a restricted environment (e.g., sandbox) • Not allowed to access the local file systems • Except for loading trusted classes that are locally available • Can only access data/programs from the remote machine where it came from. • Prevent using the client as the platform to attack other machines

49. Sandbox

50. Sandbox (more details)