Two advantages
- Creating a server with the MQTT library I make it with 3 lines of code and that's it.
- The next job I will start I have to use MQTT and so I get experience
Two advantagesWhat are the advantages of creating an MQTT server instead of one based on websockets?
It's a bit annoying to see your progress... without being able to have the source code (right @Xfood? ? )
Sorry, no sourceI agree, I hope that as soon as the project completes it makes the source available
not even for sale?Sorry, no source
What are the advantages of creating an MQTT server instead of one based on websockets?
No, because despite having created the library that does almost everything automatically, it is not easy to make it work and understand the mechanism. I want to avoid them pestering me with questions while I work because they can't get it to work.not even for sale?
ok, for me there is no problem, you know I never bother you, you can send me the source as soon as you complete it. Thank you.?????No, because despite having created the library that does almost everything automatically, it is not easy to make it work and understand the mechanism. I want to avoid them pestering me with questions while I work because they can't get it to work.
Why?This is because Websocket isn't extremely well suited to IoT devices.
Google saying..Why?
On the forum you will find many explanations of Erel on this.Why?
This can only make the server slower rather than faster.Unlike the WebSocket which is 'one to many', MQTT works as 'many to many', similar to a chat, every message sent by a client is automatically forwarded to all those listening on the channel.
Creating a server with the MQTT library I make it with 3 lines of code and that's it.
It depends on the needs. However, on mqtt auction write on specific channels and receive them only some or only one. However, I need everyone to receive.This can only make the server slower rather than faster.
If the server sends all the messages it receives and passes them on to all the connected clients (then each client must read the message and check if it is useful for it) it doesn't seem like an advantage, far from it.
In my opinion you have more control with a websocket server and no downside.
Implementation with B4J is also just as simple.
...the server not sends... just open and wait for client (that not means... all client will the same time... but the message will wait - that is good)... it is different layer of TCP and not works the same with http... MQTT brokers have different philosophy... I agree if they are too many clients will be slow... (it depends to the type of app)...This can only make the server slower rather than faster.
If the server sends all the messages it receives and passes them on to all the connected clients (then each client must read the message and check if it is useful for it) it doesn't seem like an advantage, far from it.
It is more likely that if you try a b4j websocket server you will fall in love with itps: If you tried once ... you will "love" it
but ofcourse I am loving it tooIt is more likely that if you try a b4j websocket server you will fall in love with it
We use cookies and similar technologies for the following purposes:
Do you accept cookies and these technologies?
We use cookies and similar technologies for the following purposes:
Do you accept cookies and these technologies?