• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 203
  • Last Modified:

Get two programs to talk to eachother on two separate LANs (send messages?)

Hi Experts

I need to send a message from my application on LAN 1 to my application on LAN 2, which simply needs to reply back Yes or No.

This is in deepest darkest Africa so I can only assume there will be some basic internet connectivity using maybe GPRS / 3G technology, or something like that, but probably not ADSL.

I need to know what components I need to use in Delphi, what protocol I would be using, would I be targeting a port, and some source code wouldn't hurt :)

Thank-you in advance.
5 Solutions
Well, if connectivity was going to be a problem, I'd implement a store and forward mechanism to communicate. That requires a system that both systems can access all the time, which makes me think internet.

Have a machine online that acts as a go between, or use an exisiting system, such as email, jabber, irc, (irc is a stretch), but you understand my point here, right?

I'm saying don't build a new communications protocol for store and forward, use exitsing mechanisms, and use encryption where neccessary.
rfwoolfAuthor Commented:
The problem with store and forward is that it isn't instant. PC 1 stores the message on the irc 'server' and PC 2 needs to know to check for new messages every few minutes which is unideal. Even email would be a similar thing.
Can't we have direct communication here?
In which case if there's a connectivity problem at one site, the communication will just time out I guess
Bill BachPresidentCommented:
The simplest method of DIRECT communications would be to implement a UDP message passing scheme.  For something like this, though, the two computers would need to be able to see each other on the public network.  However, your original message indicated LAN1 and LAN2, which supposes that the networks will be somewhat protected from each other (likely by a firewall on each LAN).

Let's look at some options:
1) Direct UDP traffic:
- Very Easy to code, but low level
- Short and efficient messages
- No guarantee of delivery
- Direct IP access required (so firewall hole may be needed)
2) Direct TCP traffic
- Fairly Easy to code, but still low level
- Short and efficient messages, but it also supports larger messages
- Guaranteed delivery
- Direct IP access required (so firewall hole may be needed)
3) Relayed UDP traffic:
- Very Easy to code, but low level
- Short and efficient messages
- No guarantee of delivery -- more likely to lose data since now each is sent twice
- You have to ALSO code a relay system on a public server
4) Direct TCP traffic
- Fairly Easy to code, but still low level
- Short and efficient messages, but it also supports larger messages
- Guaranteed delivery
5) Web Services
- Fairly easy to code at the high level, well understood by many developers
- Higher bandwidth requirements
- Web server must be available on the public 'Net, but client does not.
6) Email Relay
- Very easy to code, and well understood
- Messages can be short or large as needed
- Need to write an Email parser, although several ETL tools (like Pervasive's Data Integrator) can handle this automatically
- Neither system needs a public address, but both need Email account access.

There are likely to be several other solutions, which will be allowed or disallowed by your exact network configuration.
Free Tool: Path Explorer

An intuitive utility to help find the CSS path to UI elements on a webpage. These paths are used frequently in a variety of front-end development and QA automation tasks.

One of a set of tools we're offering as a way of saying thank you for being a part of the community.


BillBach hit it on the head as far as protocols. UDP is never guaranteed to be delivered. TCP is... generally.

It does sound like Internet connectivity is present and there has to be (must be, is better) some form of firewall/router on the other end there in deepest darkest Africa. You cannot just send a UDP or TCP packet from one IP to another and expect it to reach the target machine. You will have to port forward through this end device to your target machine.

As an example only....

Lets say you use UDP port 10000. The end user public or Internet IP address is The PC or machine address you need to send/receive to at this Public IP is You have to port forward UDP port 10000 to ip Then simply send your packets from your PC connected anywhere in the world to the INternet to IP

Indy has some GREAT examples/demos on how to code simple to complex IP communications for UDP and TCP. If you use UDP, ensure you get an ack (acknowledgment of some sort back).


You can also use delphi components TServerSocket and TClientSocket. Those use TCP protocols.

I highly recommend you use Indy 9 and first check out the demos. All code is there... it just makes it easy.

If you need anything else, ask...

More on port forwarding....

Some higher end firewalls will allow you to only port forward from a specific Public IP address. Those will also generally allow any public IP address to have its specific ports forwarded. Lower end home type firewall routers seem to only allow port forwarding from ANY public IP address.

Just some more information depending upon security needed.

Geert GOracle dbaCommented:
direct communication
you'll need a VPN (virtual private network)

or both ip addresses will have to be static internet ip adresses
or use a dynamic dns service like DynDNS OR dns2go etc.

Most VPNs need some pass through and port forwarding through a firewall/router as well.

rfwoolfAuthor Commented:
Thanks John... I hate how with my questions by the time I get decent answers I am already ahead of that answer.
By the time I received your response I had already tried Indy to death and finally (after  much frustration) solved the problem - er, well at least I think I have.
My Delphi has Indy 10. All the good demos are Indy 9, and the only relevant Indy 10 demo I could get used SSL IOHandlers and the SSL DLLs never worked. So I had to change all the SSL IOHandlers to 'Stack' IO Handlers, which is incredible because I don't know the difference between Stack and Stream IO HAndlers.
Anyways, it worked in my demo.

Also the answers I got about port forwarding and VPNs I finally understand now from weeks of investigating VPNs.

Thanks for all the help, I'll let you know if I encounter any problems
rfwoolfAuthor Commented:
Geert> Thanks for the comment... You are correct I will need static IP addresses. Further to what I was saying in John, fortunately I already know this :) I proposed DynDNS but then the director moved to interacting with a US server. I used DYNDNS for our server here at the office and I'm not 100% happy with it - I can never be sure when it's working 100% even using its software which is not intuitive enough.
Given the potential problems with DYNDNS I am inclined to also support the US Server option. But we're still working on it
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

Featured Post

Free Tool: Port Scanner

Check which ports are open to the outside world. Helps make sure that your firewall rules are working as intended.

One of a set of tools we are providing to everyone as a way of saying thank you for being a part of the community.

Tackle projects and never again get stuck behind a technical roadblock.
Join Now