Recent

Author Topic: Ways of having two applications talk to one another on the same computer...  (Read 7703 times)

c_knowles4834

  • New Member
  • *
  • Posts: 25
Hello all,

I was wondering if anyone knew of a way to have two applications talk to one another as they both run on the same computer? 

Being that I am very new to the world of programming and want to challenge my abilities a bit, I had the idea of creating a messaging application that I could run with two windows that are independent of one another but can have text messages sent between them.

I have done some reading on this topic but cannot find anything substantial or conclusive to warrant a solution to my problem.  Any advice will help!

Thanks,

Handoko

  • Hero Member
  • *****
  • Posts: 5129
  • My goal: build my own game engine using Lazarus
One of the thing can be used to let (two) programs to communicate on the same computer is IPC.

You posted this question under MacOS sub forum, not sure but in the link below you can find an IPC demo (simpleipc) that works on Linux and Windows:

https://wiki.freepascal.org/Portal:HowTo_Demos#General

PierceNg

  • Sr. Member
  • ****
  • Posts: 369
    • SamadhiWeb
I have a pair of Pascal programs talking to each other over ZeroMQ. Production usage is on Linux but programs also tested working on MacOS, and across network between Linux and MacOS.

ZeroMQ provides the transport. For application payload I used Protocol Buffers; other possibilities include JSON and msgpack.


loaded

  • Hero Member
  • *****
  • Posts: 824
One of the thing can be used to let (two) programs to communicate on the same computer is IPC.
I didn't know that either. Today, I learned something new this morning, thank you handoku.
Have a nice day brother.
Check out  loaded on Strava
https://www.strava.com/athletes/109391137

dbannon

  • Hero Member
  • *****
  • Posts: 2786
    • tomboy-ng, a rewrite of the classic Tomboy
...
You posted this question under MacOS sub forum, not sure but in the link below you can find an IPC demo (simpleipc) that works on Linux and Windows:
...

Will work fine on the Mac too. I use IPC in tomboy-ng, works exactly the same on all three platforms. Easy and reliable.

Davo
Lazarus 3, Linux (and reluctantly Win10/11, OSX Monterey)
My Project - https://github.com/tomboy-notes/tomboy-ng and my github - https://github.com/davidbannon

c_knowles4834

  • New Member
  • *
  • Posts: 25
Sorry fellas for the confusion, I forgot to mention that I am working on a macOS (Big Sur v. 11.6 to be exact).

I appreciate the help though, I will give your suggestions a try!

Thanks!

ChrisR

  • Full Member
  • ***
  • Posts: 247
My cross platform solution is to use shared memory. For Windows, you use a Mutex
  http://msdn.microsoft.com/en-us/library/windows/desktop/ms682411%28v=vs.85%29.aspx

For Unix you use shmget
  https://man7.org/linux/man-pages/man2/shmget.2.html


Here is my code:

  https://github.com/rordenlab/MRIcroGL/blob/master/yokesharemem.pas/

You can try this out in a compiled application:
  https://github.com/rordenlab/MRIcroGL/releases
Choose File/NewWindow to open a new instance. If the Display/Yoke menu item is toggled, clicking on one location in one image shows you the corresponding image in another.

I agree with @dbannon that IPC is a good solution as well. I would use shared memory if you have a very simple, fixed amount of data, whereas IPC allows a lot more flexibility.

jollytall

  • Sr. Member
  • ****
  • Posts: 306
If you start a new communication interface from scratch, I would recommend to use sockets. I know it might sound a bit of an overkill, but if you have a unit that does socket communication well, you can always use it later for inter-computer communication as well. Also it is probably more platform independent than other solutions.
I think developing it is a useful investment for the future...

jwdietrich

  • Hero Member
  • *****
  • Posts: 1232
    • formatio reticularis
If you start a new communication interface from scratch, I would recommend to use sockets. I know it might sound a bit of an overkill, but if you have a unit that does socket communication well, you can always use it later for inter-computer communication as well. Also it is probably more platform independent than other solutions.
I think developing it is a useful investment for the future...

This sounds reasonable, but according to the Wiki article on sockets the unit is deprecated. Is this incorrect or are only parts of the Sockets package deprecated?
function GetRandomNumber: integer; // xkcd.com
begin
  GetRandomNumber := 4; // chosen by fair dice roll. Guaranteed to be random.
end;

http://www.formatio-reticularis.de

Lazarus 2.2.6 | FPC 3.2.2 | PPC, Intel, ARM | macOS, Windows, Linux

Thaddy

  • Hero Member
  • *****
  • Posts: 14197
  • Probably until I exterminate Putin.
Correct.

Use fpsock from the fcl-net package instead.
Specialize a type, not a var.

MarkMLl

  • Hero Member
  • *****
  • Posts: 6676
This sounds reasonable, but according to the Wiki article on sockets the unit is deprecated. Is this incorrect or are only parts of the Sockets package deprecated?

In fairness, he might have been making a general point rather than referring to a specific RTL/FCL unit or package.

However there are so many variants of sockets (TCP/UDP in both the inet and unix domains) and so many wrappers with varying degrees of sophistication (including lots of stuff based on HTTP, as well obviously as MQTT) that it's difficult to know where to begin.

The IPC unit (noting that this is distinct from the general topic of "Inter-Process Communication") is probably as good a place as any, but I'd suggest that it's always worth researching what it's using at a lower level in a given context.

MarkMLl
MT+86 & Turbo Pascal v1 on CCP/M-86, multitasking with LAN & graphics in 128Kb.
Pet hate: people who boast about the size and sophistication of their computer.
GitHub repositories: https://github.com/MarkMLl?tab=repositories

jollytall

  • Sr. Member
  • ****
  • Posts: 306
This sounds reasonable, but according to the Wiki article on sockets the unit is deprecated. Is this incorrect or are only parts of the Sockets package deprecated?

In fairness, he might have been making a general point rather than referring to a specific RTL/FCL unit or package.

Indeed. My point simply was, that if you start from scratch understanding and developing various options to use for communication between application then why not to start it with something that is also working among computers. Nowadays, the most used is IP based communication with TCP or UDP. On any operating system, there surely is a mechanism to access the Internet, i.e. can communicate. Also on any machine I know, you can use localhost (is it called something else on any system?) to loopback your requests to your own machine. So anything that is good for inter-machine is also good for intra-machine, but not vice-versa.
My comment was a bit misleading for two reasons: "sockets" I meant TCP/UDP, but not unix sockets, as that is only for intra-machine communication. Also there is a "sockets" unit you found, but I did not refer to any particular implementation. Sockets is old, fpsock is recommended as a replacement, but you can go as "overkill" (sorry, if I offend anyone) as the otherwise amazing Indy.

PascalDragon

  • Hero Member
  • *****
  • Posts: 5446
  • Compiler Developer
If you start a new communication interface from scratch, I would recommend to use sockets. I know it might sound a bit of an overkill, but if you have a unit that does socket communication well, you can always use it later for inter-computer communication as well. Also it is probably more platform independent than other solutions.
I think developing it is a useful investment for the future...

This sounds reasonable, but according to the Wiki article on sockets the unit is deprecated. Is this incorrect or are only parts of the Sockets package deprecated?

No, the wiki page is about the package. The Sockets unit is the recommended way.

Correct.

Use fpsock from the fcl-net package instead.

No, the FpSock unit is not cross platform and also prone to memory leaks. Use the SSockets unit which is a wrapper around Sockets and also supports SSL and which is the base for TFPHTTPClient, TFPHTTPServer and friends.

Sockets is old, fpsock is recommended as a replacement, but you can go as "overkill" (sorry, if I offend anyone) as the otherwise amazing Indy.

Again, no, the Sockets unit provided by FPC is the base unit used by things like TFPHTTPClient and such. The Sockets package provided by older Lazarus versions is deprecated. Also don't use FpSock.

MarkMLl

  • Hero Member
  • *****
  • Posts: 6676
My comment was a bit misleading for two reasons: "sockets" I meant TCP/UDP, but not unix sockets, as that is only for intra-machine communication. Also there is a "sockets" unit you found, but I did not refer to any particular implementation. Sockets is old, fpsock is recommended as a replacement, but you can go as "overkill" (sorry, if I offend anyone) as the otherwise amazing Indy.

I'd emphasise that unix sockets use the standard sockets API, they're distinct from pipes etc. As such and in particular because they don't rely on a numbered port, IMO they're to be preferred for same-host master-slave communications.

MarkMLl
MT+86 & Turbo Pascal v1 on CCP/M-86, multitasking with LAN & graphics in 128Kb.
Pet hate: people who boast about the size and sophistication of their computer.
GitHub repositories: https://github.com/MarkMLl?tab=repositories

 

TinyPortal © 2005-2018