Introduction
This session is designed to familiarize with available IPC methods by comparing and contrasting techniques so that you may effectively decide which ones to use. I will also illustrate strengths and weaknesses of each method and provide starting points for implementing each method.
Because of time limitations, this session will consist of only a few examples.
Types of IPC
Local
Local IPC is for communication among process on a single machine. Local IPC is useful for data sharing, signaling, and synchronization.
Mutexes, semaphores, and events can be named, or unnamed (identified by handle) and can be protected by NT permissions.
Atoms
Atoms are globally available strings or integer values identified by a handle. Atoms were typically used for DDE. The global atom table is also limited to 37 strings total. I do not recommend the use of atoms as they seem to be outdated. Instead, other more up to date IPC mechanisms should be used.
Shared Memory
Shared memory is a block o f memory which multiple processes can access. Under Win16 all memory was accessible by any process so pointers could be just passed between processes. Win32 has memory protection mechanisms, and a processes memory is virtually mapped to that process. Win32 however can map a block of memory into multiple processes virtual memory spaces. Even though the shared block of memory may appear to be at different locations to each process, each will point to the same physical location in memory. In addition, this mechanism allows you to control which processes have access to shared memory blocks. Win32 can also map a disk file into virtual memory. Because of this, when shared memory is used, it is called a memory mapped file.
Win32 also does this to the code segment of executables. When multiple instances of an executable are loaded, only one copy of the code is loaded into physical memory, while it is mapped into multiple virtual spaces.
Mutexes
A mutex (Mutual Exclusion) is an object which can be owned, but only owned by a single thread at a time. Any other thread trying to gain ownership, will be blocked and queued in order of requests. Mutexes are used to control exclusive access to any global object, or non reentrant code. Mutexes can be used to control access to shared memory, hardware, or other single access items.
Semaphores
A semaphore is like a mutex, except that a specified number of threads can own a specific semaphore at one time. When the semaphore is created, this number is specified. Semaphores are typically used to limit access to resources. An example of this might be to prevent "thrashing" of a resource by setting the maximum number of threads which can concurrently access the object.
Critical Sections
Critical sections are similar to mutexes, however mutexes differ from critical sections in that they can be accessed across processes and threads, while a critical section, can only be access across threads from within the same process. Critical sections are also lighter weight, cannot be named, or have security attributes assigned to them.
Events
An event is an object which threads can wait for to be triggered. Any free thread may then trigger the event, which will then release the other waiting threads. An event can be used to hold threads from accessing something that has not been initialized or ready yet. They can also be used to signal that input is available, or a device is ready to accept more data.
Messages
Messages can be used to send a one way queued instructions/status to a single thread. You can send messages to an existing windows message queue, and filter them as they come in, or create your own queue within a secondary thread. Messages are good for non time critical communications, or to serialize handling. Messages can contain only a limited amount of data however. Each message can contain only one 16 bit integer, and one 32 bit integer. When communicating between threads, pointers may be passed in the 32 bit parameter. However when communicating between processes pointers may not be passed, even when the pointer identifies shared memory as each process may see the shared memory at a different location in its virtual space. Object handles (Mutexes, semaphores, events) cannot be passed in the message data, however such handles can be duplicated, and the duplicated handles may be passed via the message data. (See DuplicateHandle)
DDE
DDE (Dynamic Data Exchange) was the common way to externally control applications in the 16 bit world. DDE is still used occasionally, however it has been strategically replaced by COM. You should use Com instead of DDE, unless the application you need to communicate with only understands DDE. DDE also tends to be slow, and the built in DDE in Delphi/C++ Builder is "less than perfect".
Clipboard
The clipboard can also be used for IPC, however in most situations it is not advisable as it is a global resource.
OLE/Com
OLE (Object Linking & Embedding) has evolved into COM (Component Object Model). COM allows you to do many things. With COM you can create language independent objects, expose interfaces from applications to allow external control, and much more. COM allows you to expose interfaces. An interface is a defined set of methods and properties which allow you to proxy calls to any code or object that you wish. An interface is like a contract. Any time that the interface is implemented, all of its members must be implemented.
Network
Network IPC is for communication between processes on different machines.
Network Protocols
Network protocols allow you the most flexibility, however they bind you to a single protocol, and require a lot of extra programming. Most times you do not need this flexibility and it is better to use a higher level protocol. Network protocols are also lighter weight.
Some common protocols used for network communication are IPX/SPX (Novell), NetBEUI (Microsoft), and TCP/IP (Internet).
NetBios is also a protocol, but it is a slightly higher protocol than the others. It abstracts some of the features of the other network protocols while still providing you with most of their advantages. NetBioss main feature is that is does not bin you to a particular protocol which your network configuration and/or hardware may dictate. NetBios commonly runs on top of NetBEUI or TCP/IP.
If you do decide you need to work at the network protocol level, TCP/IP is probably your best bet. It is very flexible, in widespread use (The internet runs on it), works with any operating system, has tons of existing services, and has become the de facto standard.
Mailslots
Mailslots are like messages except that they can be sent across a network. Mailslots also differ from messages in that they are not arbitrarily limited in the amount of data they can contain, and mailslots can be broadcast to a group of receivers. Mailslots however are sent as datagrams, and therefore are not guaranteed to arrive at their destination. Mailslots are similar to TCP/IPs UDP mechanism, but at a slightly higher level. If delivery must be guaranteed, another method should be used.
Pipes
A pipe is a communication channel with two endpoints. Pipes are similar to TCP connections. Pipes however can be optionally named, and contain security attributes. Pipes can also be one or two way. Pipes are used both for network communication, and locally. For example, the console is a pipe. If you want to open a DOS session / command window, you can swap a pipe for its standard in and standard out, thus giving your application full control of the window.
RPC
RPC (Remote Procedure Calls) allow you to make function/procedure calls in which the code actually executes on another system. RPCs are typically used with older systems, mainframes, or for implementing distributed object systems.
Distributed Objects
Distributed objects are used for communication among objects. These objects can be local or remote. This easily allows you to distribute your programs with complete abstraction of location. The two most common distributed object standards are DCom and Corba.
Without distributed object systems, developers need to implement their own protocols and also decide upon and program for a network transport. In many cases they also tie their protocol to a specific language, and even a platform. Distributed object systems abstract the user from all this and provide a high level interface which is platform independent, language independent, and network protocol independent.
DCom
DCom is just a distributed version of COM (Component Object Model). DCom is controlled by Microsoft and therefore is tied heavily to Win32 and other Microsoft technologies. The specification is available for other platforms, but is rarely used. For all intents and purposes, DCom is for WinTel only. DCom is also heavily tied to NT security. If you have lots of users that do not have NT accounts, this may pose a major headache for you. NT security can be bypassed by using the Midas socket server (Ive been told you do not need a Midas license to merely use this single component).
Corba
Corba (Common Object Request Broker Architecture) is a platform independent distributed object protocol. Corba is also implemented by many vendors including Inprise/Visigenic. This allows you to choose your implementation. The Corba standard is controlled by the OMG (Object Management Group). You can find tons of Corba information at their web site http://www.omg.org
220
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
