Lecture 3: Sockets, Remote Procedure Calls

1. Lecture 3: Sockets, Remote Procedure Calls

2. Last time: Pitfalls when developing distributed systems • The network is reliable • Latency is zero • Bandwidth is infinite • Transport cost is zero • The network is secure • The topology does not change • There is one administrator • The network is homogeneous [aka Peter Deutsch’s “8 fallacies”]

3. Last time: Architectural Styles for Distributed Applications

4. Summary so far: • Definition of distributed systems • collection of independent components that appears to its users as a single coherent system • Goals, pitfalls, scalability techniques, architecture styles Requirement: Components need to communicate • Shared memory • Message exchange • need to agree on many things • Protocols: data formats, exception handling, naming, …

5. Types of communication protocols: Persistence and Synchronicity • Synchronicity: Does the sender wait for a reply or acknowledgement? • Yes  synchronous communication • No  asynchronous communication • Persistence: Do the sender and the receiver have to be both online for the message exchange to happen? • No  persistent communication • Yes  non-persistent communication

6. Persistence and Synchronicity … (II) • Persistent communication of letters back in the days of the Pony Express. • Asynchronous, Persistent

7. Persistence and Synchronicity … (III) 2-22.1 Persistent synchronous communication Persistent asynchronous communication

8. Persistence and Synchronicity … (IV) 2-22.2 Receipt-based transient synchronous communication Transient asynchronous communication

9. Getting more hands on • Crash course on socket programming

10. process process TCP with buffers, variables TCP with buffers, variables socket socket Socket-programming using TCP Socket: a ‘door’ between an application process and an end-end-transport protocol (UCP or TCP) TCP: reliable transfer of bytesfrom one process to another controlled by application developer controlled by application developer controlled by operating system controlled by operating system internet host or server host or server

11. Client must contact server server process must first be running server must have created socket (door) that welcomes client’s contact Client contacts server by: creating client-local TCP socket specifying IP address, port number of server process client establishes connection to server TCP When contacted by client, server TCP creates new socket for server process to communicate with client allows server to talk with multiple clients source port numbers used to distinguish clients TCP provides reliable, in-order transfer of bytes (“pipe”) between client and server application viewpoint Socket programming [with TCP]

12. State machine

13. Example: echo – client public class TCPEchoClient { public static void main(String[] args) throws IOException { String server = args[0]; // Server name or IP address byte[] byteBuffer = args[1].getBytes(); int servPort = (args.length == 3) ? Integer.parseInt(args[2]) : 7; // Create socket that is connected to server on specified port Socket socket = new Socket(server, servPort); System.out.println("Connected to server...sending echo string"); InputStream in = socket.getInputStream(); OutputStream out = socket.getOutputStream(); out.write(byteBuffer); // Send the encoded string to the server // Receive the same string back from the server int totalBytesRcvd = 0; // Total bytes received so far int bytesRcvd; // Bytes received in last read while (totalBytesRcvd < byteBuffer.length) { if ((bytesRcvd = in.read(byteBuffer, totalBytesRcvd, byteBuffer.length - totalBytesRcvd)) == -1) throw new SocketException("Connection close prematurely"); totalBytesRcvd += bytesRcvd; } socket.close(); // Close the socket and its streams } }

14. Example: echo – server public class TCPEchoServer { private static final int BUFSIZE = 32; // Size of receive buffer public static void main(String[] args) throws IOException { int servPort = Integer.parseInt(args[0]); // Create a server socket to accept client connection requests ServerSocket servSock = new ServerSocket(servPort); int recvMsgSize; // Size of received message byte[] byteBuffer = new byte[BUFSIZE]; // Receive buffer for (;;) { // Run forever, accepting and servicing connections Socket clntSock = servSock.accept(); // Get client connection System.out.println("Handling client at " + clntSock.getInetAddress().getHostAddress()); InputStream in = clntSock.getInputStream(); OutputStream out = clntSock.getOutputStream(); // Receive until client closes connection, indicated by -1 return while ((recvMsgSize = in.read(byteBuffer)) != -1) out.write(byteBuffer, 0, recvMsgSize); clntSock.close(); // Close the socket. We are done with this client! } } }

15. First assignment • Client for “encoding server”. • Protocol • Client sends: four byte integer (your student ID) • Server replies with message containing • Length of useful code (four bytes) • ‘Secret’ unique encoding of your ID (as a set of bytes to be converted to a string) • Padding (junk) • Closes connection • Submit individually: • Your client • The ‘secret’ encoding you’ve got by successfully running your client

16. Remote Procedure Calls

17. Communication oriented design Start with communication protocol; Design message format and syntax Design components (clients, servers) by specifying how they react to incoming messages Problems Protocol design problems Specify components as finite state machines Focus on communication instead of on application RPC offers support here! Application-oriented design Start with application Design, build, test conventional (single-box) application Partition program Problems Preserving semantics when using partitioning program (using remote resources) Masking failures Concurrency Building Distributed Applications: Two Paradigms

18. Building distributed applications RPC goal: minimize the difference between a single box and a distributed deployment environment Observations: • Application developers are familiar with simple procedure model • Well-engineered procedures operate in isolation (black box) • There are few reasons not to execute procedures on separate machines Idea: communication between caller & callee can be hidden by using procedure-call mechanism. • (local program calls procedures hosted remotely in a similar way to local procedures)

19. Remote Procedure Calls (RPC) • Idea: local program calls procedures hosted remotely in a similar way to local procedures • Information is passed in procedure arguments, results • Problem: Provide transparency • Mask difference in data representation • Handle failures • Different address spaces • Security (?)

20. Outline • Mechanics. • How does it actually work … • … and limitations • RPC in practice. • Case study: The Network File System • Discussion: • Reliable RPC • Asynchronous RPC

21. Conventional (local) Procedure Call count = read(fd, buf, bytes) Parameter passing in a local procedure call – the stack before & after the call

22. Passing Value Parameters • Steps involved in doing remote computation through RPC 2-8

23. Parameter passing - Parameter marshaling More than just wrapping parameters into a message: • Client and server machines may have different data representations (think of byte ordering) • Client and server have to agree on the same encoding: • How are basic data values represented (integers, floats, characters) • How are complex data values represented (arrays, structures)

24. Steps of a Remote Procedure Call. Stubs • Client procedure calls client stub in normal way • Client stub builds message calls local OS • Client's OS sends message to remote OS • Remote OS gives message to server stub • Server stub unpacks parameters, calls server • Server does work, returns result to the stub • Server stub packs it in message, calls local OS • Server's OS sends message to client's OS • Client's OS gives message to client stub • Stub unpacks result, returns to client

25. Parameter passing (II): Problems: Pointers and global data What happens with pointers and references to global data? Traditional parameter-passing possibilities: • By value • Parameter value is copied on the stack and/or sent on the wire • By reference • Reference/Identifier is passed • How does this work for remote calls? • Copy in/copy out • A copy of the referenced object is copied in/out • While procedure is executed, nothing can be assumed about parameter values Do they lead to different results after a procedure call?

26. Discussion: Pointer and global variable handling An simple example. But things are more complex …..

27. Outline • Mechanics. How does it actually work … • … and limitations • RPC in practice. • Case study: The Network File System • Discussion: • Reliable RPC • Asynchronous RPC

28. RPC in mechanics practice Objective: Let the developer concentrate on only the client- and server-specific code; let the RPC system (generators and libraries) do the rest. What components does an RPC system consist of? • Standards for wire format of RPC msgs and data types. • Example: Sun’s XDR • Library of routines to marshal / unmarshal data. • Stub generator or RPC compiler, to produce "stubs". For client: marshal arguments, call, wait, unmarshal reply. For server: unmarshal arguments, call real fn, marshal reply. • Server framework: Dispatch each call message to correct server stub. • Client framework: Give each reply to correct waiting thread / callback. • Binding mechanisms: how does client find the right server?

29. RPC in practice: Writing a Client and a Server • The steps in writing a client and a server in DCE RPC. 2-14

30. Practicalities: Binding a Client to a Server Issues: • Client must locate the server machine • Client must locate the server (port) 2-15

31. Discussion: Did we achieve transparency? Yes: • Hides wire formats and marshal / unmarshal. • Hides details of send / receive APIs • Hides details of transport protocol (TCP vs. UDP) • Hides who the client is. No: • Global variables / concurrency • Failures