Ed Rees - Inter-process communication using Clarion

by Tom Hebenstreit, Review Editor

Published 1997-09-01    Printer-friendly version

Have you ever wished that two of your programs could talk to each other? That they could easily send messages or data back and forth between them? Even better, that those programs could be either on the same machine or on different machines across a network? And that, best of all, you wouldn't have to worry about the dirty details of how to manage all of this?

You have? Well, Ed Rees of Information Packaging Unlimited has a new item for you to add to programming bag of tricks: Inter-Process Communications.

What the heck is Inter-Process Communications?

Put most simply, Inter-Process Communications (IPC) is a fancy term covering any method by which one program (a "process" in Windows API speak) can to "talk" to another program (process). As a concept, it encompasses everything from using shared files (or a database) to exchange information to using advanced (i.e., very complex) technologies like RPC (Remote Procedure Calls) and OLE (Object Linking and Embedding) to do the communicating.

In his presentation, though, Ed focused on a section of IPC which he defined as 'Synchronous (Live) Messaging': the capability of two (or more) concurrently running programs to talk to each other regardless of their locations. They can be on the same machine, or on any other machine (or machines) across your network. The key point was that as long as there is an active connection between them, they can talk to each other.

Nerd warning: Ed's presentation covered a lot of very technical material in a very short period of time, with Ed striving to fit a presentation that could easily take a couple hours into approximately 50 minutes. As a matter of fact, my brain started to hurt about half way through... (just kidding!). Don't let that scare you away though - just like the presentation, there will be gold at the end of this tunnel, and it will definitely make the journey well worth your time.

The Big Picture

Ed discussed three different but similar methods of IPC, all of which are already built-in to Windows. They are called: 'Pipes', 'Sockets', and 'Mailslots'. Do they all do basically the same thing (provide IPC communications services)? Yes. Are there particular advantages or disadvantages to the various methods? You bet, and they have to do with speed (how fast they work), flexibility (what kind of limits are placed on data sizes, etc.), and finally, which of the methods you can use depending version(s) of Windows your programs are running under. Am I going to explain all of the benefits, mechanisms, restrictions and so forth for each of the methods which Ed discussed right here? No way (remember the headache?) -- but here is the gist of it...

• All of the methods require that your programs make some calls to the Windows API to initialize the selected method of IPC, and to provide some kind identifier or handle which all other programs will use to direct messages and/or data to it. Once that is done, your programs can either send or respond to messages as appropriate (subject to the basic restraints or capabilities of that method).
• Each of the three different methods provide various options for communications, which may (or may not) include: A) Whether a connection is maintained between messages or dropped after each message, B) What types and size of messages or data can be sent and received, C) Whether your program stops and waits for a response to a message it sends or whether is sends it and then continues on its merry way, and finally, D) Are the communications sessions established on a one to one basis or can they broadcast messages to multiple machines at one time.
• Problems which may arise include: A) Finding one another - can a particular program's name or handle be located (remember, the program has to be up and running to send and/or receive messages), B) Making sure your programs understand the messages or data sent to them (all data or messages are defined by you, the programmer) and, C) making sure that the conversations between machines don't get hung up with, for example, program A waiting for a response from program B, which is waiting for a response from program A, etc., etc.

The good stuff!

Just about the time that one began to feel the effects of total information overload, Ed pulled the proverbial rabbit out of his hat - three versions of the same really nifty demo program (one for each of the three methods: Named Pipes, Sockets and Mailslots). All of that complexity suddenly became secondary to the fact that these programs showed exactly how each IPC method works and, more importantly, how remarkably little code it actually takes to add such powerful capabilities to your programs. What does the demo program do?

In essence, it lets you start up an IPC message server window in the demo after providing a name for it ('dog', for example). You can then start up a message sender window in the same program which you also name (say, 'cat'). The sender then begins automatically generating messages every five seconds or so, and you see the server ('dog') began to receive messages from 'cat'. Want to start more senders? No problem, just fire them up and name them. Want to see it work between multiple programs? Start another instance of the demo and create (and name) more send windows to send to 'dog'. You will see the server window in the first program suddenly began getting messages from the second program. Want to see the first program send messages to the second as well as receive them? Got a network? Fire up and name some more, and so on, and so on...

And the answer to the obvious question is....

YES! You can download the demo yourself (all three versions), from the World Wide Web site maintained by Information Packaging Unlimited:

http://www.cwsuperpage.com

(Note: this is a very nice Clarion related site/resource - check it out!)

The Powerpoint presentation file used by Ed is also available there as well, and it contains a pretty good amount of information relating to the various methods. Note: not all versions of the programs will run under all versions of Windows (due to restrictions built in by Microsoft such as 32-bit vs. 16-bit, etc.). For example, a Named Pipe server can only be started under Windows NT. I'd recommend trying the MailSlots or Sockets demos first...

Printer-friendly version

Copyright © 1999-2008 by CoveComm Inc. All Rights Reserved. Reproduction in any form without the express written consent of CoveComm Inc., except as described in the subscription agreement, is prohibited.

Clarion Magazine ISSN 1718-9942