Send message frmo VCL app to another machine in lan

[mikak 2]

Hi,

I need to implement somekind of message exchange between two similar VCL apps inside same local network. All are windows machines.

I have been thinking following options

1. install local mosquito server and use TMS mtqq client
2. build websocket server (for example using mORMot) 
3. brute force: write to DB and read using  timer based poll (not a real option IMO)

 

use case is that user can press help on self service kiosk and it would raise notification in service personal desktop app.  Or there is an error and application automatically sents notifcation .

 

Also considering in future to have handheld (android) devices to receive messages.

 

is there another reasonable choices?

 

[Alberto Fornés 15]

Maybe Tethering also can be used in that scenario.

[Lars Fosdal 1730]

TMS MQTT sounds like a good choice. Disclaimer: I have not used it myself.

 

But - plan ahead for service discovery.  Query a discovery server for a valid endpoint config. Query again if a new discovery server is detected.  Query that server for the actual MQTT connection to use, then connect. 

Because, servers come and go.

[FPiette 363]

1 hour ago, mikak said:

I need to implement some kind of message exchange between two similar VCL apps inside same local network. All are windows machines.

This is really a short description which is not enough for us to advice for solutions.

For me the easiest way to exchange messages between two similar VCL application is to use simple TCP socket to make the apps peer-to-peer. You don't need complex solution if there are only two applications.

If you tell us more about the real problem you have to solve (The requirement), you will probably get a better answer.

 

[PeaShooter_OMO 10]

9 minutes ago, FPiette said:

For me the easiest way to exchange messages between two similar VCL application is to use simple TCP socket to make the apps peer-to-peer. You don't need complex solution if there are only two applications

I agree.

 

No need to limit yourself by using "just-another-server-client" framework. By using a proper TCP framework like ICS or Indy you will have total control and will be able to easily expand in future.

Edited December 21, 2022 by PeaShooter_OMO

[mjustin 19]

1 hour ago, mikak said:

1. install local mosquito server and use TMS mtqq client

 

Messaging over MQTT (or STOMP etc.) has the advantage that there is a dedicated server for communication, which handles message integrity, redelivery, persistence already out-of-the-box.

There are many MQTT-capable message brokers available besides Mosquito. It depends on your target infrastructur and client types which is the best choice.

For example, these message brokers support MQTT (and many other protocols):

* Apache ActiveMQ (classic) - https://activemq.apache.org/components/classic/

* Apache ActiveMQ Artemis - https://activemq.apache.org/components/artemis/documentation/

* RabbitMQ - https://rabbitmq.com/documentation.html

 

They also seem to support MQTT over WebSockets, which means clients may just use the HTTP port to connect.

 

[Sherlock 627]

Also keep in mind, if this software is supposed to be commercial you will have to look into encrypting the communication. TLS will have to be minimum.

[Zoran Bonuš 12]

If you already use a DB that supports events/notifications (Firebird, Interbase, Oracle, MSSQL...?), a FDEventAlerter (or similar) may be sufficent to notify clients (instead of polling).

https://docwiki.embarcadero.com/RADStudio/Sydney/en/Database_Alerts_(FireDAC)

[mikak 2]

48 minutes ago, FPiette said:

This is really a short description which is not enough for us to advice for solutions.

For me the easiest way to exchange messages between two similar VCL application is to use simple TCP socket to make the apps peer-to-peer. You don't need complex solution if there are only two applications.

If you tell us more about the real problem you have to solve (The requirement), you will probably get a better answer.

 

Yes, In deed it was short description.
there will be 2 ... n windows pc's which run our VCL application. Some are self service kiosks ( Point of Sales) and some have employees operating them.   Configuration might be for example 4 self services and 2 with personel.
In kiosk users make mistake which required staff's actions.  Accidently orders wrong product and pays it, employees help is needed to cancel it.  Or age limited product, staff could click It's ok from his own terminal if he / she see that customer is and old guy. Anyway in these cases self service terminals application sends msg to all (configured) manned workstations.  Personel could send command (ok - continue,  wait-i'll be there) from own workstion back to originaiting selfservice kiosk.

usually messages are from one terminal to another, but might be brodcast also.

 

So my current plan is that number of messages quite few and they might be short. Of course if implementation works we might extend it more, like manned workstation could see what user does in self service kiosk. (not whole screen, only items purchased).

Current envirmoments are all in own private local area cable network, so encryption isn't a must. But it will if in some day customers wan't to use stand alone clients.

Our DB is Actian Zen (old btrieve) so no notification 😞

 

thanks for responses so far 🙂 intresting reading.

 

[FPiette 363]

44 minutes ago, mikak said:

there will be 2 ... n windows pc's which run our VCL application.........

That's a better explanation of your requirement.

I still persist to the socket idea, using SSL to make the connection secure. ICS component can be used for that (Freeware with full source code. See http://wiki.overbyte.be).

 

Each workstation will have a listening TCP socket to receive messages from others (TWSocketServer). In your situation, probably all workstation are perfectly known (You could have a table in your database with all the hostname). When one workstation has to send a message to another, it will use a TCP client socket (TWSocket) to connection to the other (one or more in a loop) where the message has to be sent. It is better that the receiver reply with an OK answer or an error (Much like standard protocols are working [HTTP, FTP, SMTP and many others]). You could use text based messages much like many other protocols. Each message is a text line. This is easy to implement with TWSocket/TWSocketServer since there is a "line mode" in which the OnDataAvailable is triggered only when a complete line is received (Usually end-of-lin is CR/LF pair but you can select whatever you prefer). The use of SSL or not is quite transparent. The programming effort is low.

 

If you need help with ICS, there is a dedicated support forum  on this website: https://en.delphipraxis.net/forum/37-ics-internet-component-suite/

Just ask for your questions.

 

BTW: There are a number of other socket components/libraries. ICS is just my favorite (I wrote it and make it available with full source code). Any will probably do what you need.

Edited December 21, 2022 by FPiette

[Uwe Raabe 1879]

Some information about App Tethering: Using App Tethering

[mvanrijnen 121]

10 hours ago, Lars Fosdal said:

TMS MQTT sounds like a good choice. Disclaimer: I have not used it myself.

 

But - plan ahead for service discovery.  Query a discovery server for a valid endpoint config. Query again if a new discovery server is detected.  Query that server for the actual MQTT connection to use, then connect. 

Because, servers come and go.

We use this now, for inter app/device communication (local lan for now). 

No discovery, but configuration through dns text records (local lan), chang of server etc will be detected (polling dns with interval).  So we can have some apps without config files etc.

 

Edited December 21, 2022 by mvanrijnen

[DelphiUdIT 132]

I'm implementing a new feature to the software I've produced that used e-mail as an alert. Now I'm also testing mosquitto as a server and I'm rebuilding a new MQTT client starting from an old repository on github https://github.com/wizinfantry/delphi-mqtt-client

(that version is not working with new enviroment and needs some refresh).

The current version of mosquitto supports up to the latest version of MQTT (MQTT 5.0 https://docs.oasis-open.org/mqtt/mqtt/v5.0/os/mqtt-v5.0-os.pdf), SSL (up to TLS 1.3), TCP or websockets. Also you can connect to other brokers.

And with retains, there's no problem at all losing alerts, especially using mobile devices as clients.

In my opinion, since the server (broker) is already ready, implementing MQTT having a good Delphi "component" allows you to easily manage alerts.

Bye

P.S.: in this Embarcadero article there is more info and link to a client and broker MQTT write in Delphi: https://blogs.embarcadero.com/learn-how-to-use-the-mqtt-protocol-in-delphi-with-this-library/

Edited December 21, 2022 by DelphiUdIT

[mvanrijnen 121]

Forgot to mention, one of the advantages of a protocol like MQTT (there are other solutions with this advantage) is that you do not have to configure firewall on the workstations, only the server (incoming mqtt port), the clients just have an outgoing connection (most of the time allowed by firewalls),

We had a solution first where client app's where listining on certain port, but this way we needed multiple ports per client, so also configuring the firewalls etc, that has fallen away now with the mqtt solution.

Edited December 22, 2022 by mvanrijnen

[miab 25]

Maybe use a chat solution, examples of which you'll find for network communication libraries like ICS or INDY.

[miab 25]

Or maybe a database server application with clients polling every now and then is enough?

[mikak 2]

4 hours ago, mvanrijnen said:

Forgot to mention, one of the advantages of a protocol like MQTT (there are other solutions with this advantage) is that you do not have to configure firewall on the workstations, only the server (incoming mqtt port), the clients just have an outgoing connection (most of the time allowed by firewalls),

We had a solution first where client app's where listining on certain port, but this way we needed multiple ports per client, so also configuring the firewalls etc, that has fallen away now with the mqtt solution.

Actually I was just thinking about this. It came from differenent case where I got complaint from customer that purchase price in order  doesn't change immediatly in when user changes price in product maintenance in another workstation.  tought I could use same mecanishm to send messages. then I rememberd that some of workstation are dhcp, change and some are event in different subnet (warehouse vs storage). Had to configure many terminal.
I will go with MQTT.

[mvanrijnen 121]

5 minutes ago, mikak said:

Actually I was just thinking about this. It came from differenent case where I got complaint from customer that purchase price in order  doesn't change immediatly in when user changes price in product maintenance in another workstation.  tought I could use same mecanishm to send messages. then I rememberd that some of workstation are dhcp, change and some are event in different subnet (warehouse vs storage). Had to configure many terminal.
I will go with MQTT.

i wonder if thats the best solution for the use case your describing (just) now. 

(just maybe a database event may just be better here .....)

But mostly article prices have a startdate/enddate, so i wonder how big the customers problem is? What about if the government decides to change sales tax at 13.15 hour ? , change the order pricing/totals also?
 

Edited December 22, 2022 by mvanrijnen

[DelphiUdIT 132]

2 hours ago, mikak said:

Actually I was just thinking about this. It came from differenent case where I got complaint from customer that purchase price in order  doesn't change immediatly in when user changes price in product maintenance in another workstation.  tought I could use same mecanishm to send messages.
I will go with MQTT.

I don't understand very well what you are thinking to do. But remember that MQTT is not a database, it doesn't present you a storytime of alerts, it works on time basis and is totally asynchronous. If i publish a message (thinking that is a retain), until this message "stay" there all can view that, but when the message will clear (or change) .... who read the message its ok, the workstations that were offline and cannot read that "lost that message".

 

Of course you can publish a message like a storyboard shifting all every time, but this is not the scope of the MQTT.

 

If you made a broker or can control a broker, of course you can know how many clients are online and you can decide what to do.

 

Bye

Edited December 22, 2022 by DelphiUdIT

[FPiette 363]

2 hours ago, mikak said:

Actually I was just thinking about this. It came from differenent case where I got complaint from customer that purchase price in order  doesn't change immediatly in when user changes price in product maintenance in another workstation.  tought I could use same mecanishm to send messages. then I rememberd that some of workstation are dhcp, change and some are event in different subnet (warehouse vs storage). Had to configure many terminal.
I will go with MQTT.

The solution I depicted with TCP socket can as easily applied when using a server dedicated to be a "exchange" server. MQTT is a complex product and Delphi implementation is likely to depend on a number of other product.

Whatever solution you select, I advise you to only use products for which you'll get FULL SOURCE code and you'd never use prebuilt libraries or DCU but instead recompile yourself everything. This is the only way to be sure that in the future you'll be able to have your own product survive to the death of the external product you used.

 

[mjustin 19]

1 hour ago, DelphiUdIT said:

... But remember that MQTT is not a database, it doesn't present you a storytime of alerts, it works on time basis and is totally asynchronous. If i publish a message (thinking that is a retain), until this message "stay" there all can view that, but when the message will clear (or change) .... who read the message its ok, the workstations that were offline and cannot read that "lost that message".

Not sure if I understand the scenario, but messages can be configured so users will see them when back online. This is called a durable client (or durable subscription).

For reference see https://stackoverflow.com/questions/34150452/receive-offline-messages-mqtt

So, somehow the broker is a database, but specialized for asynchronous messaging.

 

(Disclaimer: I dont have any 'expert knowledge' with MQTT, but its features are very similar to those of other open source message brokers I am using)

 

 

Edited December 22, 2022 by mjustin
shortened the quote

[Tom Chamberlain 45]

1 hour ago, FPiette said:

The solution I depicted with TCP socket can as easily applied when using a server dedicated to be a "exchange" server. MQTT is a complex product and Delphi implementation is likely to depend on a number of other product.

Whatever solution you select, I advise you to only use products for which you'll get FULL SOURCE code and you'd never use prebuilt libraries or DCU but instead recompile yourself everything. This is the only way to be sure that in the future you'll be able to have your own product survive to the death of the external product you used.

 

I agree, if you have the enterprise version of Delphi you could use DataSnap to create your own "exchange" server that way you control both sides.  We use the DataSnap callback feature to register and unregister clients for by-directional communications via the TJSONValue so we have a dynamic message but still have structure.  We validate concurrent usage licensing, request "check-ins",  send user messages and can even terminate the clients.  There is some DataSnap overhead but with a few clicks and every little code you can add authentication, compress and encryption. (encryption does require the deployment of 2 OpenSSL DLL's) 

 

There is nothing wrong with MQTT or other options, they are all good.

 

 

[DelphiUdIT 132]

2 hours ago, mjustin said:

Not sure if I understand the scenario, but messages can be configured so users will see them when back online. This is called a durable client (or durable subscription).

For reference see https://stackoverflow.com/questions/34150452/receive-offline-messages-mqtt 

So, somehow the broker is a database, but specialized for asynchronous messaging.

 

(Disclaimer: I dont have any 'expert knowledge' with MQTT, but its features are very similar to those of other open source message brokers I am using)

If one publish a "retain" message, this message will remain "online" until it will be clean or override (eg. publish another message, retain or not). While the message is retain every one can subscribe and receive it. If the message it's clear or override, it's lost for ALL. MQTT is designed to maintain only the last message. Of course I talk about one "topic", one can publish as many topic as he wants.

 

Bye

Edited December 22, 2022 by DelphiUdIT

[mikak 2]

11 hours ago, FPiette said:

Whatever solution you select, I advise you to only use products for which you'll get FULL SOURCE code and you'd never use prebuilt libraries or DCU but instead recompile yourself everything. This is the only way to be sure that in the future you'll be able to have your own product survive to the death of the external product you used.

 

This has been my guideline all the time when talking about delphi code.  and it has saved me couple of times. But sometimes must relay on ready solutions but use those who have large user base.  One just don't have enough time to write everything by himself ( = myself + my team)

[esegece 46]

Hello,

 

If you just need to exchange messages between clients, any of the proposed solutions will work, a publish/subscribe pattern is enough for your needs and any of the solutions can implement this pattern.

 

1. MQTT is usually used on constrained nets where bandwidth is important, the most common usage is working as a sensor, example: sending temperature every x seconds. 

2. You can use any TCP library and implement your own Server and Client, using queues to store the messages exchanged between clients. I recommend Indy which is free, included with any Delphi version, supports all personalities and works very well.

3. WebSocket protocol has the advantage that using the same server implementation, is supported on VCL and WebBrowsers clients. Also has other features like compression, sub-protocols... As an example, I've a presence demo that allows to know who is subscribed to a channel, and exchange messages between peers, this can be useful for applications like chat rooms, collaborators on a document, people viewing the same web page, competitors in a game... find below a link of the compiled sample if you want to test it and get a better idea of how works.

 

https://www.esegece.com/download/protocols/ProtocolPresence.zip

 

Kind Regards,

Sergio