Add MQTT over WebSocket support [SPR-12581]

[spring-projects-issues]

pascal gehl opened SPR-12581 and commented

STOMP over websocket is really nice as starting point but for resource-constrained devices and low bandwidth (lots of mobile out there running on small data plans and not necessarily 4G) it would be nice to be able to choose MQTT instead of STOMP when implementing websocket based messaging.

---

Issue Links:

• Support WAMP messaging protocol [SPR-11665] #16288 Support WAMP messaging protocol

6 votes, 17 watchers

[spring-projects-issues]

Juergen Hoeller commented

Rossen, for consideration in 4.2...

[spring-projects-issues]

Rossen Stoyanchev commented

Right along with WAMP support (#16288)..

[spring-projects-issues]

Rossen Stoyanchev commented

MQTT (client) support in Spring Integration based on the Eclipse Paho client:
http://docs.spring.io/spring-integration/reference/html/mqtt.html

[spring-projects-issues]

Rossen Stoyanchev commented

pascal gehl I've done some some basic prototyping using the Eclipse Paho browser client and RabbitMQ (with MQTT enabled) as the backing broker. While I was able to relay messages in both directions, an important observation to make is that since all WebSocket messages are binary we won't be able to support SockJS fallback transports. Currently the SockJS protocol does not support binary messages and it probably won't without "evidence of demand". See this recent exchange for example sockjs/sockjs-protocol#74 (comment).

How much does that matter to you? I would imagine that even if mobile phones have a WebSocket client available, there is still the issue with network proxies interfering over the public Internet.

[spring-projects-issues]

pascal gehl commented

Thanks a lot Rossen for your quick answer.
I understand your point and it will provide me some meat to "sell" STOMP to my team.
We will go with STOMP and see where it goes from there.

[spring-projects-issues]

Rossen Stoyanchev commented

Okay it would be great to get some further thoughts. We could make the case for binary support in SockJS, that kind of feedback would be required at a minimum. From a Spring Framework perspective MQTT over WebSocket for 4.2 looks quite feasible.

[spring-projects-issues]

Rossen Stoyanchev commented

Postponing until we get more votes and motivation.

[spring-projects-issues]

Puran Singh commented

Just voted :) @Rossen, do you happen to have any samples of the prototyping you did with MQTT to relay messages? Would love to look at it. Thanks!

[spring-projects-issues]

Rossen Stoyanchev commented

Thanks puran. Unfortunately I seem to have lost the local branch following a corruption of my git index not long ago. That will teach me to always push to my own fork as a backup. It would be interesting if you share more of your thoughts on this. Especially as it relates to the fact that (currently) SockJS does not support binary data and we can't provide HTTP fallback options.

[spring-projects-issues]

Puran Singh commented

Basically, I am trying to use that setting for mobile apps and don't really need SockJS, at least for now. So, trying to just relay a message via spring websocket connection from a device to MQTT server

[spring-projects-issues]

Rossen Stoyanchev commented

I see, chances are however that you do need SockJS (or something like it) since over the public Internet a WebSocket connection could be closed by a proxy.

[spring-projects-issues]

Puran Singh commented

Yeah most probably. But, for mobile at least in my case I am assuming it won't be an issue. If connection is dropped I can always send background push notification and re-establish a connection. Also, at this point I am only concerned about text based but didn't want to use STOMP since I may do binary data in future.
Thanks

[spring-projects-issues]

Rossen Stoyanchev commented

Okay good to know, thanks! I'll try to re-establish a branch and publish that.

Also for what it's worth re-establishing the connection may not necessarily be a successful strategy, at least not against proxies that deliberately close the connection.

[spring-projects-issues]

Puran Singh commented

Yeah you are right. Specially with mobile networks, and their proxies! Though, using it over SSL port 443 seems to solve this issue. I haven't tested it myself!

[spring-projects-issues]

Rossen Stoyanchev commented

Almost forgot to mention. STOMP does support binary data payloads.

[spring-projects-issues]

Rainer Frey commented

FWIW, I have a use case in mind where this would be helpful: a Spring Boot application that connects with MQTT enabled devices, and a small set of users in a controlled environment where I can afford to exclude users for whom websockets don't work. That specific project is a small hobby project with low priority though.

It would certainly not be too hard to adapt/relay different protocols, with either the application or RabbitMQ, but using a single protocol would still be nice.

[rstoyanchev]

Closing as we have no plans to add this.