1 / 49

Chapter 11

Chapter 11. Interprocess Communication. OBJECTIVES. Upon completion of this chapter, you will be able to: Describe the Windows interprocess communication mechanisms Describe the different capabilities of anonymous pipes, named pipes, and mailslots

kendall
Télécharger la présentation

Chapter 11

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 11 Interprocess Communication

  2. OBJECTIVES • Upon completion of this chapter, you will be able to: • Describe the Windows interprocess communication mechanisms • Describe the different capabilities of anonymous pipes, named pipes, and mailslots • Use the Windows interprocess communication facilities to develop applications with cooperating processes • Be prepared to learn and use the synchronization mechanisms in the next module

  3. IPC ALTERNATIVES • Byte- and message-oriented Windows objects • Pipes (anonymous and named) • Mailslots (subject of this chapter) • Networking • Windows sockets (standard interface to TCP/IP) • Remote Procedure Calls (RPCs) • Object-oriented • OLE; COM (Component Object Model) • Some others • Shared memory with memory-mapped files • Files

  4. OVERVIEW (1 of 2) • Interprocess Communication (IPC) is provided with byte- and message-based “pipes” • Anonymous pipes • Well suited for redirecting the output of one program to the input of another • Anonymous pipes are stream oriented

  5. OVERVIEW (2 of 2) • Named pipes • Allow networked communication • Multiple handles on the same pipe • Transaction-oriented named pipe functions • Ideal for creating simple client/server systems • Named pipes are message oriented • Mailslots allow for one-to-many message broadcasting

  6. TOPICS • Topic I Anonymous Pipes • Lab 6–A • Topic II Named Pipes • Topic III Mailslots • Lab 6–B

  7. TOPIC I Anonymous Pipes

  8. ANONYMOUS PIPES • Allow for one-way (half-duplex), character-based IPC • Two handles: a read handle and a write handle • Specify the suggested buffer size for the pipe • Usually you want the pipes to be inheritable

  9. IPC USING AN ANONYMOUS PIPE pipe CreatePipe (&hRead, &hWrite) StartUp.hStdOutput = hWrite CreateProcess ("Program1") StartUp.hStdInput = hRead CreateProcess ("Program2") WaitForMultipleObjects Program1 Program2 hIn = CreateFile (argv [1]) while ( ) { ReadFile (hIn) WriteFile (hWrite) } ExitProcess (0) hOut = CreateFile (argv [2]) while ( ) { ReadFile (hRead) } WriteFile (hOut) Pipe

  10. ANONYMOUS PIPE MANAGEMENT(1 of 2) • BOOL CreatePipe (PHANDLE phRead, • PHANDLE phWrite, • LPSECURITY_ATTRIBUTES lpsa, • DWORD cbPipe)

  11. ANONYMOUS PIPE MANAGEMENT(2 of 2) • cbPipe • The pipe byte size; use zero to get the default value • phRead • Address of a HANDLE • CreatePipe will set *phRead • phWrite is used for the write handle to the new pipe • Reading blocks if pipe is empty; otherwise read will accept as many bytes as are in the pipe, up to the number specified in the ReadFile call • Writing to a full pipe will block

  12. LAB 6–A (1 of 2) • We now have a collection of command line utilities, including cat, ls (with options for file size and security), grep, and sort (several versions) • Write a program, pipe, which will take two commands and connect them with anonymous pipes (assigned to standard input and output) • Use the = sign to separate the two program names • Use the model in the anonymous pipe figure. The original input is standard input and the results are to go to standard output.

  13. LAB 6–A (2 of 2) • Command form: pipe Program1 = Program2 • An additional utility, the wc word count program, is included with the solutions • It is useful in the role of Program2

  14. TOPIC II Named Pipes

  15. NAMED PIPES (1 of 2) • Good mechanism for implementing IPC-based applications, including limited networked client/server systems • Use WinSockets for serious networked IPC • Use named pipes primarily for single-system IPC • Message-oriented, so the reading process can read varying length messages precisely as sent by the writing process

  16. NAMED PIPES (2 of 2) • Bi-directional, so two processes can exchange messages over the same pipe • You can create multiple, independent instances of a named pipe • Several clients can communicate with a single server using the same pipe • Server can respond to a client using the same instance • Pipe name can be accessed by systems on a network

  17. Up to N Clients CLIENTS AND SERVER USINGNAMED PIPES Client 0 h = CreateFile (PipeName); while ( ) { WriteFile (h, &Request); ReadFile (h, &Response) /* Process Response */ } CloseHandle (h); Server /* Create N instances */ for (i = 0; i < N, i++) h [i] = CreateNamedPipe (PipeName, N); /* Poll each pipe instance, get request, return response */ i = 0; while ( ) { if PeekNamedPipe (h [i]) { ReadFile (h [i], &Request); /* Create response */ WriteFile (h [i], &Response); } i = i++ % N; } Pipe Instance 0 · · · · Client (N-1) h = CreateFile (PipeName); while ( ) { WriteFile (h, &Request); ReadFile (h, &Response) /* Process Response */ } CloseHandle (h); Pipe Instance N-1

  18. USING NAMED PIPES (1 of 2) • The model above has two significant shortcomings: • The server polls the named pipe handles rather than waiting for a connection or a request. This will be fixed in the next lab. • It can only process one client request at a time. This will be fixed using threads in the next module. Also, a suggested extension in this module’s lab shows how to use multiple processes.

  19. USING NAMED PIPES (2 of 2) • CreateNamedPipe creates the first instance of a named pipe and returns a handle • The creating process is regarded as the server • Client processes, possibly on other systems, open the pipe with CreateFile

  20. CREATING NAMED PIPES (1 of 5) • HANDLE CreateNamedPipe (LPCTSTR lpszPipeName, • DWORD fdwOpenMode, DWORD fdwPipeMode, • DWORD nMaxInstances, DWORD cbOutBuf, • DWORD cbInBuf, DWORD dwTimeOut, • LPSECURITY_ATTRIBUTES lpsa) • lpszPipeName indicates the pipe name • Must be of the form \\.\pipe\[path]pipename • You cannot create a pipe on a remote machine

  21. CREATING NAMED PIPES (2 of 5) • fdwOpenMode specifies one of: • PIPE_ACCESS_DUPLEX • Equivalent to GENERIC_READ | GENERIC_WRITE • PIPE_ACCESS_INBOUND — Data flow is from the client to the server only • Equivalent to GENERIC_READ • PIPE_ACCESS_OUTBOUND • The mode can also specify FILE_FLAG_WRITE_THROUGH (not used with message pipes) and FILE_FLAG_OVERLAPPED

  22. CREATING NAMED PIPES (3 of 5) • fdwPipeMode has three mutually exclusive flag pairs indicating whether writing is message- or byte-oriented, whether reading is by messages or blocks, and whether read operations block • PIPE_TYPE_BYTE and PIPE_TYPE_MESSAGE • Mutually exclusive • Writing stream of bytes or messages • Use the same type value for all pipe instances

  23. CREATING NAMED PIPES (4 of 5) • PIPE_READMODE_BYTE and PIPE_READMODE_MESSAGE • Reading stream of bytes or messages • PIPE_READMODE_MESSAGE requires PIPE_TYPE_MESSAGE • PIPE_WAIT and PIPE_NOWAIT determine whether ReadFile will block • Use PIPE_WAIT as there are better ways to achieve asynchronous I/O

  24. CREATING NAMED PIPES (5 of 5) • nMaxInstances — the number of pipe instances and, therefore, the number of simultaneous clients • Specify this same value for every CreateNamedPipe call for a given pipe • PIPE_UNLIMITED_INSTANCES allows the OS to base the number on available system resources • cbOutBuf and cbInBuf advise the OS on the required size of input and output buffers • dwTimeOut — default time-out period (in milliseconds) for the WaitNamedPipe function • lpsa is as in all the other “Create” functions

  25. POLLING • BOOL PeekNamedPipe (HANDLE hPipe, • LPVOID lpvBuffer, DWORD cbBuffer, • LPDWORD lpcbRead, LPDWORD lpcbAvail, • LPDWORD lpcbMessage) • Nondestructively reads any bytes or messages in the pipe • Does not block • Returns immediately • Test *lpcbAvail to determine whether there is data in the pipe

  26. NAMED PIPE CLIENT CONNECTIONS • A client can “connect” to a named pipe using CreateFile with the named pipe name • In many cases, the client and server are on the same machine, and the name would be of the form: \\.\pipe\[path]pipename • If the server is on a different machine, the name would be: \\servername\pipe\[path]pipename • Using the name “.” when the server is local, rather than the local machine name (this is faster)

  27. NAMED PIPE STATUS FUNCTIONS(1 of 2) • Two functions are provided to interrogate pipe status information • GetNamedPipeHandleState returns information, given an open handle, on whether the pipe is in blocking or non-blocking mode, whether it is message- or byte-oriented, the number of pipe instances, and so on • SetNamedPipeHandleState allows you to set the same state attributes

  28. NAMED PIPE STATUS FUNCTIONS(2 of 2) • Another function is provided to set state information • GetNamedPipeInfo determines whether the handle is for a client or server instance, buffer sizes, and so on

  29. NAMED PIPE CONVENIENCE FUNCTIONS (1 of 7) • Given a “long-lived” connection, you can combine the WriteFile, ReadFile client sequence • There are also performance advantages as a connection is not required

  30. NAMED PIPE CONVENIENCE FUNCTIONS (2 of 7) • BOOL TransactNamedPipe (HANDLE hNamedPipe, • LPVOID lpvWriteBuf, DWORD cbWriteBuf, • LPVOID lpvReadBuf, DWORD cbReadBuf, • LPDWORD lpcbRead, LPOVERLAPPED lpa) • Both output and input buffers are specified • *lpcbRead — The message length

  31. NAMED PIPE CONVENIENCE FUNCTIONS (3 of 7) • BOOL CallNamedPipe (LPCTSTR lpszPipeName, • LPVOID lpvWriteBuf, DWORD cbWriteBuf, • LPVOID lpvReadBuf, DWORD cbReadBuf, • LPDWORD lpcbRead, DWORD dwTimeOut)

  32. NAMED PIPE CONVENIENCE FUNCTIONS (4 of 7) • Synchronous: Create/Write/Read/Close client “short-lived” connection • Minimizes instance use but increases connection overhead • Specifies time-out period for the connection, in milliseconds or one of: • NMPWAIT_NOWAIT • NMPWAIT_WAIT_FOREVER • NMPWAIT_USE_DEFAULT_WAIT

  33. NAMED PIPE CONVENIENCE FUNCTIONS (5 of 7) • BOOL WaitNamedPipe • (LPCTSTR lpszPipeName, • DWORD dwTimeOut) • The client can wait for an instance of the named pipe to become available

  34. NAMED PIPE CONVENIENCE FUNCTIONS (6 of 7) • BOOL ConnectNamedPipe • (HANDLE hNamedPipe, • LPOVERLAPPED lpo) • BOOL DisconnectNamedPipe • (HANDLE hNamedPipe) • With lpo set to NULL, ConnectNamedPipe will return as soon as the server has a connection from a client

  35. NAMED PIPE CONVENIENCE FUNCTIONS (7 of 7) • Normal return value is TRUE • Return value is FALSE if the client connected between the server’s CreateNamedPipe call and the ConnectNamedPipe call • In this case, GetLastError returns ERROR_PIPE_CONNECTED • Perform ReadFile, WriteFile operations between connect and disconnect

  36. NAMED PIPE SECURITY • The important security rights for named pipes are: • GENERIC_READ • GENERIC_WRITE • SYNCHRONIZE (allowing a thread to wait on the pipe) • You normally get the appropriate rights depending on the access (duplex, inbound, outbound) • All three require SYNCHRONIZE

  37. CLIENT-SERVER NAMED PIPES USING A SHORT-LIVED CONNECTION Client Server CreateNamedPipe ConnectNamedPipe WaitNamedPipe CreateFile WriteFile ReadFile WriteFile DisconnectNamedPipe ReadFile CloseHandle

  38. TOPIC III Mailslots

  39. MAILSLOTS (1 of 3) • Have names, so unrelated processes can use them for communication • Broadcast mechanisms which behave differently from named pipes • One-directional • Can have multiple readers and writers but often used in one-to-many configurations • A writer (“client”) does not know whether readers (“servers”) actually received a message

  40. MAILSLOTS (2 of 3) • Can be located over a network domain • Message lengths are limited • Each mailslot server (don’t confuse with the application or named pipe server) creates a mailslot handle with CreateMailslot • The server waits to receive a mailslot message with a ReadFile call • A write-only client should open the mailslot with CreateFile and write messages with WriteFile

  41. MAILSLOTS (3 of 3) • The open will fail (name not found) if there are no waiting readers • A client’s message can be read by all servers • They all receive the same message • The client, in performing the CreateFile, can use the form \\*\mailslot\mailslotname to connect to all mailslots with the name

  42. USING A MAILSLOT This Message is Sent Periodically Mailslot Servers Application Client 0 Mailslot Client Application Server hMS = CreateMailslot ("\\.\mailslot\status"); ReadFile (hMS, &ServerStatus) /* Connect to this Server */ while (...) { Sleep (...); hMS = CreateFile ("\\*\mailslot\status"); · · · WriteFile (hMS, &StatusInformation) } · · · Application Client N hMS = CreateMailslot ("\\.\mailslot\status"); ReadFile (hMS, &ServerStatus) /* Connect to this Server */

  43. USING MAILSLOTS (1 of 2) • One scenario: An application server, such as a database server, acting as a mailslot client, periodically broadcasts its name, named pipe name, and status information • Any application client that wants to find a server can receive this name by being a mailslot server • Note how the “client” and “server” terms are used • An application server can periodically broadcast its status (utilization, database size, etc.) to the application clients

  44. USING MAILSLOTS (2 of 2) • As shown, there is a single mailslot client (writer) and multiple readers (servers) • With multiple application servers, you would have multiple mailslot readers and writers • A bulletin board service might have a single mailslot reader and multiple writers • Alternative: The application client also acts as the MS client and broadcasts a pipe name to mailslot (and application) servers

  45. CREATING AND OPENING A MAILSLOT (1 of 3) • HANDLE CreateMailslot (LPCTSTR lpszName, • DWORD cbMaxMsg, DWORD dwReadTimeout, • LPSECURITY_ATTRIBUTES lpsa) • lpszName — Points to a mailslot name of the form: \\.\mailslot\[path]name • cbMaxMsg • Maximum size (in bytes) for messages a client can write • 0 means no limit

  46. CREATING AND OPENING A MAILSLOT (2 of 3) • dwReadTimeout — Number of milliseconds a read operation will wait • 0 causes an immediate return • MAILSLOT_WAIT_FOREVER is an infinite wait (no timeout) • The client must specify the FILE_SHARE_READ flag • Functions GetMailslotInfo and SetMailslotInfo are similar to their named pipe counterparts

  47. CREATING AND OPENING A MAILSLOT (3 of 3) • The client (writer), when opening a mailslot with CreateFile, uses the following name forms: • \\.\mailslot\[path]name • To retrieve a handle for a local mailslot • \\computername\mailslot\[path]name • To retrieve a handle for a mailslot on a specified machine • \\domainname\mailslot\[path]name • To return a handle representing all mailslots on machines in the domain • \\*\mailslot\[path]name • To return a handle representing mailslots on machines in the system’s primary domain

  48. LAB 6–B (1 of 2) • Use named pipes to connect clients (the client program) to a “command line server” • The clients take a command line and send it to a known server for execution • The server returns the results to the client over the named pipe • Design your named pipe model carefully; there are several alternatives

  49. LAB 6–B (2 of 2) • The solution consists of several components: • Client.c is built with locsrver.c • Run Client.exe in its own window • Server.c is built as Server.exe and runs in its own window or is controlled with the job management commands. Place the commands to be executed in the same directory as Server.exe. • Server.exe runs SrvrBcst.exe as a process that broadcasts the pipe name over a mailslot • Use SrvrBcst.c to build this executable • The header file, ClntSrvr.h, contains definitions used in the various programs

More Related