What is the best way to do application data exchange in Delphi without sockets?

Question

I need a few of my related applications to communicate to each other (exchange data and initiate actions). Requirements are without packages and no sockets. So I guess that leaves named pipes, WM_CopyData (like Skype does it) and command parameters. What are your best practices?

Gimmal

If I choose named pipes or WM_CopyData then I will go with REMObjects SDK, so please don't answer that. Thanks. – Gimmal

You're not looking for a design pattern, you're looking for a technology. – Leyden

You're right. I was thinking about design pattern, but my question just concentrated on the technology. The design pattern would include already chosen technology and it's implementation. Thanks for correcting that. – Gimmal

Some technologies will not work in Terminal Server Clients - for example, Named pipes will not, since they are per-system and not per-session. See stackoverflow.com/questions/851438 – Extraordinary

Answer 1

You probably have a couple of options.

Beyond what you already have:
DDE
Memory Mapped Files (MMF)
MailSlots

I would probably go with either the Pipes or the MMF.

There are a couple of free MMF components that you can download, Deborah Pate has a set of freeware classes you can use. MapFiles.zip

Check for MailSlots on Torry's site.

The final solution might be dependent on the amount, size and frequency of the data transfers that decide which option you choose.

Laxation

Answer 2

I would advise to use COM in this situation. (Attention: not COM+, not ActiveX, not OLE; COM, just COM.)

Since Delphi 7 (or an earlier version, I'm not sure), this is easily done by adding a Type Library to the project, and an Automation object.

Advantages are it's pretty widely supported, both within Delphi (the Type Library Editor has everything you need and updates your code, and COM internals and registering are catered for from the ComServ unit), and outside of Delphi (I use it in a number of project to interact with all sorts of applications: C++ projects, Word and Excel documents using VBA, oldskool ASP...).

An only disadvantage I encountered may be threading issues, in normal applications, a plain CoInitialize(nil); at application startup will do, in more complex applications, you need to think about 'threading apartments' or use free threading and do your own locking. (Which in some cases you've been doing already.)

Robinet

Note that CoInitialize() and CoUninitialize() need to be called in every thread that uses COM. – Urbanity

Just like to mention that simple creation of COM objects has been available since Delphi 3. – Acheron

Answer 3

Another alternative which is dirt simple to implement is to use the database to pass information.

Not overly elegant, and it does use a lot of overhead, but if your application is already data-aware (ie has a database as part of it), then using a table or two to pass information is pretty easy.

Griff

Answer 4

You could use simple files: One side writes to it, the other reads. If you need two way communication, just use two files, one for each direction.

Of course this is not really high performance.

Irreformable

+1 Communication via files can come in very handy once and a while. It's an easy way to communicate between different operating systems, every programming/scripting language supports it, and it's one of the few methods where information is not lost if the reader dies. Writing files with date+time in it can make it work like a queue or a stack, whichever you want. It works great as long as you're not sending hundreds of messages per second, or if every microsecond counts. – Guevara

Answer 5

Another vote from me for named pipes, for the data exchange. I like them slightly more than mmap files, since the win32 pipe APIs give you some nice choices out of the box: sync/async, byte stream vs message packets, simple ReadFile/WriteFile calls. All of which you could do yourself with mmaps... but pipes are already there...

And you can control access with security attributes -- which isn't an option with WM_CopyData. This might not be an issue immediately... but can be handy to have the option, even if you don't care who sends your app messages. For me, this was helpful when Vista came along, and suddenly user apps ran in a separate session to my service. Was good that tweaking the security attributes was the only thing needed to get things working again.

For "initiating actions", you might be able to get away with something as easy as some named Events, and not worry about sending messages at all? The interested parties simply wait for it to be signalled.

Personally, I'd avoid COM unless you have to specifically support COM-based clients.

Stelu

Answer 6

Do not use COM, too much overhead (variants) and you must register you .dll or .exe (and it gives a lot of weird installation + update problems).

I should go for MMF, I use this for communication with Windows Services. I use the following TGpMessageQueueReader and writer for this: http://17slon.com/gp/gp/gpsync.htm

Meerkat

I see this as an advantage: with normal Automation Objects, ComServ handle's the registration for you, and if you want you can use an derived object from TAutoObjectFactory, you can add to the UpdateRegistry method. (I've edited my answer to mention this) – Robinet

Also, I use native types like BSTR (which maps nicely to WideString in code) and numeric values, which perform nicely, and don't have any trouble with variants. (I never had any trouble with OleVariants anyway, what are you talking about?) – Robinet

Answer 7

If you want to pass data, call functions etc then use COM, however if there are lots of calls be aware that COM is slow. Also you might have to register the application with "xxx.exe /Regserver", before it will work.

Corwun

Answer 8

Is'nt this the sort of this that RemObjects is good at? Bri

Foliation