Chapter 4

1. Chapter 4 Inter-Process Communication (IPC)

2. On The Same Machine • Semaphors • Mutexes • Monitors

3. Message Passing • Carry explicit information • Compared to semaphores, etc. • Can be used for synchronization Header Body

4. IPC Primitives • Send/receive • Send/receive can be blocking or non-blocking • Communication can be synchronous or asynchronous • Communication can also be transient or persistent • Sockets (Java and Unix)

5. IPC Primitives (Cont.) • Send ( destination, &msg ); Receive ( source, &buf ); destination and source can be process id, port (with single receiver), or mailbox (multiple receivers) • Blocking vs. non-blocking • Non-blocking: returns after ‘minimal’ delay; only local operation is involved • Blocking receive: blocks until message available • Blocking send: different definitions

6. Communication System

7. Process A Process B User space 5 1 Kernel space 2 4 Network controller 3 What’s it for? Network Send A Message

8. Comments • In non-blocking send/receive, interrupt can be used to inform calling process when operation is complete (e.g., Unix SIGIO) • Non-blocking receive can simulate blocking receive (busy wait), but not vice versa (unless extra thread is used) • Non-blocking receive is not very useful (you cannot proceed without message)

9. Comparison • Blocking • Advantages: Ease of use and low overhead of implementation • Disadvantage: low concurrency • Non-blocking • Advantages: Flexibility, parallel operations • Disadvantages: Programming tricky: Program is timing-dependent (interrupt can occur at arbitrary time, and execution irreproducible) • Using blocking version with multi threads

10. Multi-thread for Blocking Some threads are blocked while others continue to be active.

11. Practice • Many OSs support both blocking and non-blocking versions of send/receive • With blocking version, timeout option is often available • Blocking send may also block on full buffer (no more space in send buffer)

12. Implementation Consideration • Time-out is especially important for inter-machine communication, due to possible failure of communication or remote machine • Copying to local kernel takes time, but facilitates buffer reuse by sender • If destination is on same machine, send-by-reference, is most efficient if memory can be shared, but access must be controlled after send • Copy-on-write

13. Communication • Synchronous: communication if sender blocks until some response returns from destination. • Asynchronous: not synchronous • The client is not assumed to wait for the server after issuing request • It may continue processing before reply arrives • often handled using message passing • Transient: Both sender and receiver must be up and running • Persistent: Sender and receiver need not be running at same time

14. Persistent Communication • Message stored by communication system as long as it takes to deliver • Sending application does not need to keep executing after sending • Receiving applications does not have to be executing when message sent • Needed when: • systems are large • not all parts continually connected • Handle network failure • mobility

15. Transient Communication • Message stored only as long as both sending and receiving application are executing • Can have various transient synchronous

16. Persistent Communication A stopped running. A sends message and continues. A sends message and waits until accepted. A stopped running. A A Message is stored at B’s location for later delivery. Accepted Time Time B B B is not running B starts and receives message. B is not running B starts and receives message. (a) Persistent asynchronous communication (b) Persistent synchronous communication

17. Transient Communication (1) A sends message and continues. A sends message and waits until received. A A Message can be sent only if B is running. Request is received. ACK Time Time B B B receives message. B is running but doing something else. B processes request. (c)Asynchronous communication (d) Receipt-based synchronous communication

18. Transient Communication (2) A sends request and waits until accepted. A sends request and waits for reply. A A Request is received. Accepted Accepted Request is received. Time Time B B B is running but doing something else. B is running but doing something else. Process request Process request (f) Response-based synchronous communication (e) Delivery-based synchronous communication

19. Example: E-Mail • User message sent to local mail server • Stored in temporary buffer • Subsequently sent to target mail server • Placed in mail box for recipient to read • How about RPC? • Actually delivery-based transient synchronous

20. Ways of Communication • Shared memory • Copy-on-write • Pipe • Socket • Message passing

21. Copy-On-Write • A lazy approach • Widely used • In UNIX: fork() call • Another example: String s1=“Hello”; String s4=s3=s2=s1;

22. Overheads Region size Simple copy Amount of data copied (on writing) 0 kilobytes 8 kilobytes 256 kilobytes (0 pages) (1 page) (32 pages) _ 2.7 4.82 1.4 8 kilobytes 2.9 5.12 256 kilobytes 44.8 66.4 Note: all times are in milliseconds. • Good for large region • Good for small amount of update • Less effects on system performance

23. Pipe • Pipe • Between two related processes • Processes with the same ancestor • FIFO of bounded length (normally 4KB) • No message boundaries • Heavily used in shell commands • E.g. ls -l | grep “^d” • Named pipe • Almost like file: name and permissions (but created by mknod) • Can be accessed by unrelated processes • Persistent

24. Pipe: Code Snippet if(pipe(p) == -1) { perror("pipe call error"); exit(1); } switch(pid = fork()){ case -1: perror("error: fork call"); exit(2); case 0: /* if child then write down pipe */ close(p[0]); /* first close the read end of the pipe */ write(p[1], msg1, MSGSIZE); write(p[1], msg2, MSGSIZE); close(p[1]); break; default: /* parent reads pipe */ close(p[1]); /* first close the write end of the pipe */ for(j=0; j<2; j++) { read(p[0], inbuf, MSGSIZE); } close(p[0]); }

25. agreed port any port socket socket message client server other ports Internet address = 138.37.94.248 Internet address = 138.37.88.249 Sockets And Ports • An improvement on pipe. • Based on client-server model • Originated from BSD UNIX. Now available in most modern OSs.

26. Socket Types in UNIX • Stream socket: provides for the bidirectional, reliable, sequenced, and unduplicated flow of data without record boundaries. • Very similar to pipe • Datagram socket: supports bidirectional flow of data which is not promised to be sequenced, reliable, or unduplicated • Preserve record boundaries. • Reliability guaranteed by high-level apps. • Most widely used

27. Socket Types (Cont.) • A raw socket: provides users access to the underlying communication protocols which support socket abstractions. • Not for general users • Sequenced packet socket: similar to a stream socket, with the exception that record boundaries are preserved. • Only for Xerox communication standard

28. Socket Creation: socket() • s = socket(domain, type, protocol); • A system call • domain: AF_UNIX or AF_INET • type: SOCK_STREAM, SOCK_DGRAM, etc • protocol: TCP or UDP. Auto selected if 0 • Return a socket descriptor (a small integer for later reference) • Ex: s = socket(AF_INET, SOCK_STREAM, 0);

29. Creation Failure: Reasons • Unknown protocol • Socket without supporting protocol • Any more? • Fun question: • Test the function StrtoInt(char *s) • Converting a string to an integer

30. Binding Names: bind() • Socket created without an address • Process has no way to access it. • System call: bind(s, address, len) • s: socket descriptor • address: <local address, local port> or a path name • len: the length of the address. • Why not make socket() and bind() as one system call?

31. Connection Establishment • Asymmetric, involving a server and a client • Server: createbindlistenaccept • Client: createbindconnect • connect(s, address, len) • s: socket descriptor • address: server address • len: the length of the address

32. Connection Failure • Timeout • Server down or network corrupt • Connection refused • Server not ready yet • Network down or server down • Unknown host

33. System Call: listen() • listen(s, max_num) • s: socket descriptor • max_num: the maximum number of outstanding connections which may be queued awaiting acceptance by the server process • If the queue is full, a connection will be ignored (instead of refused). Why?

34. System call: accept() • newsock = accept(s, from-addr,len) • s: socket descriptor • from-addr: to store the address of the client • Usually a pointer, could be null • len: length of from-addr • Return a new socket. Why? • Usually block the caller • Cannot select the client to be accepted.

35. Data Transfer • Once a connection is established, data flow may begin. • write(s, buf, sizeof (buf)); • send(s, buf, sizeof (buf), flags); • read(s, buf, sizeof (buf)); • recv(s, buf, sizeof (buf), flags); • Flags: provide more features • E.g.: look at data without reading

36. Discarding Sockets • close(s) • Sockets which promises reliable transmission will still attempt transfer data. • Shutdown(s, how), where how is • 0: no more receiving • 1: no more sending • 2: no more receiving or sending

37. Input/Output Multiplexing • A server/client could have multiple sockets selection issue • select(nfds, &readmask, &writemask, &exceptmask, &timeout); • nfds: number of descriptors • readmask: indicating the sockets which the caller is interested in reading • Similar for writemask and exceptmask

38. BSD UNIX Sockets server socket() bind() client listen() socket() accept() connect() Start a thread Wait for new connection accept() read() write() read() write() close() close()

39. Java Sockets server client socket() socket() accept() Start a thread Wait for new connection accept() readUTF() writeUTF() readUTF() writeUTF() close() close()

40. import java.net.* import java.io.* public class ToDServer { public static void main ( String args[ ] ) { // Create a server socket that listens on port 5555 try { ServerSocket s = new ServerSocket ( 5555 ); System.out.println ( “Server is listening ….” ); while ( true) { // Listen for connect requests Socket client = s.accept ( ); // Create a separate thread Connection c = new Connection ( client ); c.start ( ); // service the request } // end while } //end try } //end main Example Q: how to make sure there is only one object of class ToDServer?

41. Connection.java public class Connection extends Thread { private Socket clientSocket public Connection (Socket aClientSocket) { clientSocket = aClientSocket; } public void run() { try { // Here we use file IO over socket private PrintWriter pOut = new PrintWriter(clientSocket.getOutputStream(), true ); pOut.println( “The date and time is” +new java.util.Date().toString() ); clientSocket.close(); } //try } // end of run() } // end of Connection

42. Disadvantages of Sockets • Sockets are not suitable for general programming: they do not provide alternatives for buffering and synchronization. • Connection-oriented • Require connectionless communication in many cases

43. Message Oriented Middleware (MOM) • Based on message passing (obviously) • Extensive support for persistent asynchronous communication • Have intermediate-term storage capacity for messages • Neither sender nor receiver required to be active during transmission • Message can be large • Transmission time in minutes.

44. Message-Queuing • The idea of a message queue is central to MOM • A sender inserts a message in a queue • Receivers read messages from a queue • Or a group of receivers may read from the same queue • Only guarantee is that a message will be inserted in receivers queue • no guarantees about when

45. Message Brokers • Issue: message format • How to make sure the receiver understands sender’s message? • One format? • Application are too diverse. • Act as an application level gateway • E.g. change delimiters at the end of records

46. Case Study: Mach System • Developed in CMU • Target: implement much of UNIX as user-level processes • Microkernel • Support multiple systems

47. Application processes/objects Object-oriented BSD4.3 Camelot MkLinux OS/2 language UNIX Database run-time Mach kernel Multiprocessor or uniprocessor Structure

48. Features • Multiprocessor operation • Transparent extension to network operation • User-level servers • Microkernel • Operating system emulation • Flexible virtual memory implementation • Map files as virtual memory regions.

49. Concepts • Tasks: execution environment • Protected address space, collection of kernel-managed capabilities. • Threads • Ports: a unicast, unidirectional communication channel with an associated message queue. • Port rights: capabilities to send messages to a port or receive messages from a port • Can be transferred • The only way to access ports by programmers • Capability list • List of port numbers with associated rights. • Messages: can contain port rights in addition to pure data.

50. Network servers Mach Mach Uniprocessor Multiprocessor Network Key: Port Thread Thread mapping Task Processor Communications Tasks, Ports And Communication