Distributed Applications, the Easy Way

Environment: VS 6.0, VS.NET, eVC 3.0, Java 2 SE

Introduction

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.

Also, there are many types of regular applications that would benefit from splitting them into two or more parts. These are applications that perform background tasks such as 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 the user interface (UI), and the UI can be loaded only on demand.

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
  • COM/DCOM

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:

  1. Create an instance of theMessenger object (used to send a message).
  2. 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).
  3. Create an instance of the Queue object (used to receive messages).
  4. Link these objects together with couple of method calls.
  5. 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.

Downloads

Download demo - 1.9 Mb



Comments

  • u pig

    Posted by cleni on 10/27/2005 04:46pm

    only an exe

    Reply
  • Good Work

    Posted by Legacy on 02/10/2004 12:00am

    Originally posted by: Smita

    Good Work!Interesting too!

    Reply
  • kuch bhi

    Posted by Legacy on 05/12/2003 12:00am

    Originally posted by: Imran

    U've done nice job buddy

    Reply
  • brij

    Posted by Legacy on 01/31/2003 12:00am

    Originally posted by: Brijesh Jadav

    very good

    Reply
  • Well done

    Posted by Legacy on 01/29/2003 12:00am

    Originally posted by: Neville Franks

    Hi Eugene,
    Thanks for your contribution, it looks quite interesting. However a few problems and a question.

    1) Running the demo SendNote on WinXP I get quite a few:
    First-chance exception in SendNote.exe (KERNEL32.DLL): 0xE06D7363: Microsoft C++ Exception.
    after each Send. This using the default text and ip address. It seems to be when the msg is received, but I can't be 100% sure about this.

    2) readme.html and others have a Javascript error on Line 22, Char 1, Object Expected. Enable Javascript error reporting in IE to see this.

    3) "Documentation and Support" doesn't mention or link to the Help.

    4) "How do I..?" in the Help is blank.

    5) I can't see any information on using MCDataTree.

    I'm particularly interested in high performance interprocess communications. Do you have any statistics, charts etc. showing expected throughput and overhead? It would also be interesting to know how MsgConnect compares in this regard with other libraries.

    Thanks again.

    Reply
Leave a Comment
  • Your email address will not be published. All fields are required.

Top White Papers and Webcasts

  • Hybrid cloud platforms need to think in terms of sweet spots when it comes to application platform interface (API) integration. Cloud Velocity has taken a unique approach to tight integration with the API sweet spot; enough to support the agility of physical and virtual apps, including multi-tier environments and databases, while reducing capital and operating costs. Read this case study to learn how a global-level Fortune 1000 company was able to deploy an entire 6+ TB Oracle eCommerce stack in Amazon Web …

  • Protecting business operations means shifting the priorities around availability from disaster recovery to business continuity. Enterprises are shifting their focus from recovery from a disaster to preventing the disaster in the first place. With this change in mindset, disaster recovery is no longer the first line of defense; the organizations with a smarter business continuity practice are less impacted when disasters strike. This SmartSelect will provide insight to help guide your enterprise toward better …

Most Popular Programming Stories

More for Developers

Latest Developer Headlines

RSS Feeds