There are many ways of transferring data from one process to another. All those methods have some advantages, but also some drawbacks.
Is there a way to have a flexible data exchange system and don't go to deep into technical details?
When your application consists of more than one process, you face the question of optimizing communications between the processes. Such distributed applications include computational grids, peer-to-peer networks, client-server and 3-tier business applications. They all use different ways of sending information to other processes and receiving responses.
Also there are many types of regular applications, which would benefit in splitting them in two or more parts. These are applications that perform background tasks like monitoring web sites, filtering Internet traffic, scanning files and mail for viruses to name a few. Usually the business logic can be easily separated from user interface (UI) and UI can be loaded only on demand.
All these applications have something in common. This is the necessity to provide some way for data exchange between different parts of the application.
There are many ways of data exchange, which are used in different situations. Most frequently used in Windows world are (starting from the simplest):
1) Windows messages;
2) Windows mailslots;
3) Memory-mapped files (MMF);
4) TCP or UDP sockets;
5) COM/DCOM
Each of these methods has it’s own advantages. Windows messages are very easy to use and work with. Mailslots are much like Windows messages but work in local networks. Memory-mapped files are quick and relatively easy way to exchange data when you can’t work with window handles (ex. service applications, console applications). Sockets are universal and cross-platform. COM/DCOM is object-oriented and quite high-level.
However each of these methods has it’s own drawbacks. COM, Windows messages and memory-mapped files are usable within single computer only (MMF files can be opened on network drives, but the data integrity and actuality is not guaranteed). Mailslots and UDP sockets are not reliable (this means that when you send data, you can’t easily query whether the recipient has received the data successfully). TCP sockets can be used in wide variety of scenarios, but there’s one problem – they are stream-only. It is up to your application to divide stream of data into data blocks and process these blocks. DCOM is sophisticated solution that is sometimes hard to setup and maintain, and it becomes a nightmare when you start dealing with security.
No need to say, that all the described methods except sockets (and expensive 3rd-party implementations of DCOM created for Unix-based systems) are Windows-only. If you create an application that should work not only on Windows platform, you are stuck to sockets.
Sockets are very powerful solution as they let you control almost all aspects of data delivery – how and when the data are sent, how long the application waits for reply and other things. One negative aspect of this flexibility is that you _must_ control these aspects (maybe not all, but most of them).
Let’s now return to windows messages. They are really simple – a structure with several fields that can be filled with data and sent to the recipient with one call. And when you need to pass some data block, you can use WM_COPYDATA message. “How nice it would be if there were methods to use the same technique both on the same computer and across networks”, you might think. We thought the same. Unfortunately, it is not possible… Well, until now.
Now you can combine the simplicity of Windows messaging system with power and flexibility of socket communications or memory-mapped files using MsgConnect framework.
MsgConnect encapsulates low-level operations used to establish communication and exchange information and provides a simple API that looks very much like windows messaging. The sequence of actions necessary to add cross-platform communications to your application will fit into 20 lines of code:
1) create an instance of Messenger object (used to send a message);
2) create an instance of Transport object (used to deliver messages to recipients. You will need one instance of transport for each transport you use, be it sockets or MMF);
3) create an instance of Queue object (used to receive messages);
4) link these objects together with couple of method calls;
5) define a handler for event which is fired when the message is received.
That’s all. You can start sending and receiving messages.
Why would use of MsgConnect be easier than using conventional ways of communications?
First of all, MsgConnect hides the details, but keeps them available for use. The framework lets you fine-tune transport object to achieve maximum performance for any type of application, from occasional messaging to heavy data exchange. And if you don’t want to go into details, MsgConnect will work perfectly with default settings.
Of course, you will need to design the protocol, i.e. define what messages are used for different purposes in your application, and this will be a part of application business logic. You won’t need to dig into details of TCP protocol implementation or manage security for MMF.
Second thing is that message exchange is universal. With MsgConnect the message can contain any binary data and the recipient can change this data block and send it back with the same message. In other words the sides of the data exchange can do round-trip data transfer with just one message. The result is that MsgConnect can be used in both single-directional and bi-directional communications without limitations.
Third benefit is that to change the communication from local computer to network you only need to add another transport object and change the address, to which the messages are delivered. You don’t need to implement another algorithm or handle another low-level algorithm.
Forth, your application can exchange information with applications running on different platforms. MsgConnect supports a wide range of platforms (currently Windows, Windows CE, Linux, Unix, Java, .NET with more to come in near future).
And the last but not the least – whether you develop a free open-source project or a huge proprietary system, MsgConnect has a suitable license for you. It’s available as open-source and provides additional services to the users, who obtain commercial license.
In the second part of the article we will build a scheme of a simple chat system for local network, the example that covers basic topics of MsgConnect use.