B4J Question Enable Two B4J Apps to Communicate with One Another (inter-process communications)

[cklester]

I'm going to have a "boss" app and several "worker" apps running on a Windows PC, and I need the boss and workers to communicate quickly and accurately.

I think this kind of communication is called "inter-process."

I've done some research in this forum, and the options seem to be as follows:

• UDP (probably not because lossy)
• TCP/IP
• MQTT
• AsyncStreams
• Sockets

I'd like to be able to have the boss app running, and, when a worker app starts up, the worker signals to the boss that it is up and running.

And, vice versa, if one or more worker apps are running, when the boss app starts up, it can reach out to all worker apps to let it know it's ready to go.

(The workers don't need the boss app. They have functionality that they can accomplish on their own. However, additional functionality will be available with the boss app.)

What other options do I have for IPC?

What's the best option for two B4J apps to communicate with one another?

 

[Erel]

A few inaccuracies:
1. AsyncStreams is not a communication channel by itself.
2. Sockets = TCP/IP

Another possible option, if the boss app is a non-ui app, is to use jServer (http / websockets server).

UDP on the localhost will be quick and is likely to be accurate as well. I like UDP as it is simple and stateless. No need to maintain an active connection that can break million times.
Another advantage of UDP is that you can open a port without locking it (see UDPSocket.Initialize2). This solves annoying "port is already bound" errors.
If the messages are short, a few kbs, then UDP might be the best solution.

MQTT is also good.
Raw sockets with multiple clients will be more complex.
jServer can also be good.

 

[LucaMs]

And, vice versa, if one or more worker apps are running, when the boss app starts up, it can reach out to all worker apps to let it know it's ready to go.

JServer?
Could a server at its startup inform clients? It seems strange to me, right?

 

[Erel]

Good point. My previous answer was more appropriate for the simpler case where the main communication is initiated from the clients to the server.
If the server needs to communicate with a specific client then a more complex solution is required.
MQTT is probably the best option. The clients will need to try to poll the broker until a successful connection is made.
jServer with WebSockets can also be used for such communication.

In both cases the clients will need to poll the server until connected.

 

[OliverA]

Could stick with UPD. Use one UDP broadcast address that is shared between all apps to announce when an app/server fires up and listen to other apps/server firing up. Then use another standard port for app to app/ app to server communications (without polluting the broadcast channel).