views:

819

answers:

9

I have a need of implementing two apps that will exchange data with each other. Both apps will be running on separate PCs which are part of a LAN.

How we can do this in Delphi?

Is there any free component which will make it easy to exchange data between apps across PCs?

+8  A: 

If I'm writing it myself, I (almost) always use sockets to exchange data between apps.

It's light weight, it works well on the same machine, across the local network or the Internet with no changes and it lets you communicate between apps with different permissions, like services (Windows messages cause problems here).

It might not be a requirements for you, but I'm also a fan of platform independent transports, like TCP/IP.

There are lots of free choices for Delphi. Here are a few that I know of. If you like blocking libraries, look at Indy or Synapse. If you prefer non-blocking, check out ICS.

Bruce McGee
Sorry for my ignorance but what is Blocking and Non Blocking?I have never come across this terms even after programming for 15+ year now. In fact I have never come across such a requirement till date.This is for the first time that a client has asked for a facility that will allow our apps running on different PC to communicate and exchange data between them. I was actually planning to adopt DCOM but the fact is that using COM in Delphi is pure Pain in the...
Yogi Yang 007
I've had really bad experiences with DCOM as far back as the original MIDAS, which used DCOM as the default transport. If you decide to try it, do some investigation first.Blocking calls stop code execution until the call has finished. For interactive apps, these should be used in threads. Non-blocking calls return control immediately and notify you with an event when the call has completed. Both have their advantages and disadvantages.
Bruce McGee
COM in Delphi is probably the easiest way to use COM, but it's usually not the best way to work across a network. Blocking and non-blocking relates to how the operating system handles the thread that initiates I/O (a blocked thread or process is not scheduled to run until it is unblocked). Blocking I/O causes the thread to be unscheduled by the OS scheduler until the I/O completes. Non-blocking I/O doesn't block the thread, the thread keeps on running, but needs to use a callback or polling or other mechanism to notify of completion.
Barry Kelly
+1  A: 

Probably the easiest way is to read and write a file (or possibly one file per direction). It also has the advantage that it is easy to simulate and trace. It's not the fastest option, though (and it definitely sounds lame ;-) ).

dummzeuch
+1  A: 

Look at solutions that use "Remote Procedure Call" type interfaces. I use RemObjects SDK for this sort of thing, but there are open source versions of RealThinClient which would do just as well.

Both of these allow you to create a connection that for most of your code is "transparent", and you just call an interface which sends the data over the wire and gets results back. You can then program how you usually do, and forget the details of sockets etc.

mj2008
From what I have read RealThinClient is free for development only. What is the real picture about RTC?
Yogi Yang 007
Check with RTC as to the status. I think it is like MySQL in that there are "older" versions that are open, and the current one is charged for. For me, RemObjects SDK is well worth paying for - it has been very flexible.
mj2008
+3  A: 

I used to use Mailslots if I needed to communicate with more than one PC at a time ("broadcast") over a network, although there is the caveat that mailslots are not guaranteed.

For 1-to-1, Named Pipes are a Windows way of doing this sort thing, you basically open a communication channel between 2 PCs and then write messages into the pipe. Not straight forward to start with but very reliable and the recommended way for things like Windows Services.

MS offer Named Pipes as an alternative way of communicating with an SQL Server (other than TCP/IP).

But as Bruce said, TCP/IP is standard and platform independent, and very reliable.

_J_
Mailslots and named pipes both use TCP/IP for communication between machines, and are viable protocol options between applications on the same network.
skamradt
+1  A: 

This is one of those cases where there really isn't a "best" answer as just about any of the technologies already discussed can be used to accurately communicate between two applications. The choice of which method to use will really come down to the critical nature of your communication, as well as how much data must be transfered from one workstation to another.

If your communication is not time sensitive or critical, then a simple poll of a database or file at regular intervals might be sufficient. If your communication is critical and time sensitive then placing a TCPIP server in each client might be worth pursuing. If just time sensitive then mailslots makes a good choice, if critical but not time sensitive then named pipes.

skamradt
+2  A: 

Before you choose a technique, you should characterize the communication according to its throughput, granularity, latency, and criticality.

Throughput -- how much data per unit time will you need to move? The range of possible values is so wide that the lowest-rate and highest-rate applications have almost nothing in common.

Granularity -- how big are the messages? How much data does the receiving application need before it can use the message?

Latency -- when one aplication sends a message, how soon must the other application see it? How quickly do you want the receiving application to react to the sending application?

Criticality -- how long can a received message be left unattended before it is overrun by a later message? (This is usually not important unless the throughput is high and the message storage is limited.)

Once you have these questions answered, you can begin to ask about the best technology for your particular situation.

-Al.

A. I. Breveleri
+1, though I would add to the point of "criticality": Can messages be allowed to be received out-of-order or even be dropped completely?
mghie
Messages are generally withing 10k bytes at any point of time.All messages will be saved in a proprietary format compatible to a third party statistical analysis software.
Yogi Yang 007
Excellent point mghie -- I will add Ordering and Reliability to my concept of Criticality.-Al.
A. I. Breveleri
+2  A: 

DCOM used to be a good method of interprocess communication. This was also one of Delphis strong points. Today I would strongly advice against using it.

Depending on the nature of your project I'd choose either

  • using a SQL server
  • socket communication
mliesen
+1  A: 

I've used the Indy library's Multicast components (IdIPMCastClient/Server) for this type of thing many times. The apps just send XML to each other. Quick and easy with minimal connection requirements.

Gerard
A: 

For medium to large application integration, a message oriented middleware might be an option.

Message brokers offer guaranteed delivery, load balancing, different communication models and they work cross-platform and cross-language. (PHP talks to Delphi which in turn talks to Java or C# clients ...)

There are many products available, including MSMQ (Microsoft Message Queue) which is included in newer versions of Windows, and open source products like

They have a small footprint, can be installed in minutes and start up in a few seconds.

mjustin
The software will never have more than 4 PC in LAN so that is never the problem.I don't want to employ a server for this. Using a server is like calling an Elephant to pick up a twig!Thanks for suggestions.
Yogi Yang 007