WEBINAR: On-demand webcast
How to Boost Database Development Productivity on Linux, Docker, and Kubernetes with Microsoft SQL Server 2017 REGISTER >
Environment: VS 6.0, VS.NET, eVC 3.0, Java 2 SE
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 three-tier business applications. They all use different ways of sending information to other processes and receiving responses.
All these applications have something in common—the necessity to provide some way for data exchange between different parts of the application.
There are many ways to accomplish data exchange; these ways are used in different situations. Most frequently used in the Windows world are (starting from the simplest):
- Windows messages
- Windows mailslots
- Memory-mapped files (MMF)
- TCP or UDP sockets
Each of these methods has its 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 a quick and relatively easy way to exchange data when you can't work with window handles (for example, service applications and console applications). Sockets are universal and cross-platform. COM/DCOM is object-oriented and quite high-level.
However, each of these methods has its own drawbacks. COM, Windows messages, and memory-mapped files are usable on a single computer only (MMF files can be opened on network drives, but the data integrity and actuality are 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 a wide variety of scenarios, but there's one problem: They are stream-only. It is up to your application to divide the stream of data into data blocks and process these blocks. DCOM is a sophisticated solution that is sometimes hard to set up and maintain, and it becomes a nightmare when you start dealing with security.
Needless to say, all the described methods except sockets (and expensive third-party implementations of DCOM created for Unix-based systems) are Windows-only. If you create an application that should work not only on the Windows platform, you are stuck to sockets.
Sockets are a very powerful solution because they let you control almost all aspects of data delivery—how and when the data are sent, how long the application waits for a 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 the 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 the Windows messaging system with the power and flexibility of socket communications or memory-mapped files by using the 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:
- Create an instance of theMessenger object (used to send a message).
- Create an instance of the 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).
- Create an instance of the Queue object (used to receive messages).
- Link these objects together with couple of method calls.
- Define a handler for the event that is fired when the message is received.
That's all. You can start sending and receiving messages.
Why Would Using MsgConnect Be Easier than Using Conventional Ways of Communication?
First of all, MsgConnect hides the details, but keeps them available for use. The framework lets you fine tune a 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 the details, MsgConnect will work perfectly with its default settings.
Of course, you will need to design the protocol; in other words, define what messages are used for different purposes in your application. This will be a part of the application's business logic. You won't need to dig into the details of TCP protocol implementation or manage security for MMF.
The 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.
The 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.
Fourth, 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, and .NET, with more to come in near future).
And, last but not 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.
DownloadsDownload demo - 1.9 Mb