1 / 57

Chapter 4

Chapter 4. Inter-Process Communication (IPC). On The Same Machine. Semaphors Mutexes Monitors. Message Passing. Carry explicit information Compared to semaphores, etc. Can be used for synchronization. Header. Body. IPC Primitives. Send/receive

paco
Download Presentation

Chapter 4

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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

More Related