B4J Question MQTT vs Websockets

WebSockets is better for Internet based solutions.

MQTT is very good for local networks where you don't want to implement a server and especially with low-power devices such as B4R platforms.

@Erel: why do you advice on MQTT limited to LANs?
Currently I'm designing a system where a few desktop B4J apps will interact with a dedicated server where they reside on a MySQL DBMS, an MQTT server (not jMQttBroker but the plain MQTT open source server) and a B4J server (webserver or websockets to be decided). Then many B4A/B4i devices will mostly receive data from the MQTT server.
The idea is that desktops send general data to the B4J server, which in turn uses MySQL for storage, while using MQTT to talk directly to the devices.
An example of MQTT messages could be "Recall the appointment for tomorrow at 11:00" or a very simple one-to-one chat (like tech support).

What do you think? BTW, will you favor a webserver or a websocket solution to excahnge general data (small packets) between desktops and app server? In a different context I successfully used the B4XSerializator to exchange objects between desktops and a B4J webserver, but it was an experiment just to verify it could be done.

udg

Everything is possible and you can certainly use MQTT for non-local solutions.
One advantage of a http server over MQTT is that you have more control over the server and you can better protect it from malicious attacks. If your app will only be used by trusted customers then this is not an issue.

Thank you Erel.
I can confirm that users for the B4J desktop app will be trusted partners, while a mobile user could be anyone.
So partners will use an all-B4J solution to exchange critical data with the central MySQL repository while going MQTT to send less important data to the general public.

At first, I'm going to reuse code from my cited experiment, that is a desktop app sending Serialized objects to a few specialized jServer's handlers.
B4A/B4i apps will deploy an MQTT client for short messages/chat and eventually a client to interact with the jServer if later requested to do so.

The only point I'm not sure about is how the "handlers" solution stands against a pure websockets one. When should I prefer one over the other? TIA

udg said:

The only point I'm not sure about is how the "handlers" solution stands against a pure websockets one. When should I prefer one over the other?

Click to expand...

Just to make sure that it is clear, you can combine both standard handlers and websocket handlers in the same server.

Using WebSockets vs regular handlers in a backend server (not the same considerations as in a web app)

If you want to keep an open and symmetric connection between the server and client then use websockets (this includes the ability to push data from the server to the client).

If a "request -> response" flow is good enough then use regular handlers.

Remember that WebSockets work with strings instead of raw bytes. If you want to send serialized objects (with B4XSerializator) then you will need to encode the data with base 64 encoding.

I will give you a real example. The B4i Mac builders are implemented with B4J. With the exception of a single task all the tasks are implemented with regular handlers.
For example the IDE sends the project and the server compiles it and does whatever it needs to do.
The device sends a request and the builder returns the ipa as required for over-the-air installation.

The exception is the "upload to app store" feature. It can take 5 or more minutes for this task to complete. Regular requests can timeout and then you need to implement a solution based on polling.

Instead the IDE opens a WebSocket connection to the server and keeps it open until the server sends a notification to the IDE that the process has completed.

Thank you very much. Your reply really helped to clarify my doubts.

My project follows a pattern like "send a command to the server and read its feedback", so fundamentally I have two serialized objects, one to send a command and its parameters and a second one used by the server to return a feedback (eventual error code and payload for the executed command). The server never needs to initiate an exchanging of data with the client. So the handlers-only solution is enough for this project.

BTW, B4XSerializator was a great addition to our toolbox. Thanks again for it.

udg

Erel said:

and you can better protect it from malicious attacks

Click to expand...

https://www.b4x.com/android/forum/threads/how-to-react-to-spam.72970/#post-463902

Moreover I don't think there is a way to get the clients' IP using MQTT. There is "only" a ClientID and I don't know on what it is based.

Erel said:

The B4i Mac builders are implemented with B4J.

Click to expand...

I hope this is posted on b4x.com's home page

Erel said:

I will give you a real example. The B4i Mac builders are implemented with B4J. With the exception of a single task all the tasks are implemented with regular handlers.
For example the IDE sends the project and the server compiles it and does whatever it needs to do.
The device sends a request and the builder returns the ipa as required for over-the-air installation.

The exception is the "upload to app store" feature. It can take 5 or more minutes for this task to complete. Regular requests can timeout and then you need to implement a solution based on polling.

Instead the IDE opens a WebSocket connection to the server and keeps it open until the server sends a notification to the IDE that the process has completed.

Click to expand...

Why not use websockets for all kind of tasks in this case?

LucaMs said:

Why not use websockets for all kind of tasks in this case?

Click to expand...

1. Standard http communication is stateless. This is a very important aspect. You don't need to manage any connection or state. You just create a request and send it. There could be zero or more concurrent requests.
This is not the case with WebSockets.

2. Most of the data is binary data, not text.