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: - #16288 Support WAMP messaging protocol
6 votes, 17 watchers
Comment From: spring-projects-issues
Juergen Hoeller commented
Rossen, for consideration in 4.2...
Comment From: spring-projects-issues
Rossen Stoyanchev commented
Right along with WAMP support (#16288)..
Comment From: 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
Comment From: 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 https://github.com/sockjs/sockjs-protocol/issues/74#issuecomment-68842555.
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.
Comment From: 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.
Comment From: 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.
Comment From: spring-projects-issues
Rossen Stoyanchev commented
Postponing until we get more votes and motivation.
Comment From: 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!
Comment From: 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.
Comment From: 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
Comment From: 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.
Comment From: 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
Comment From: 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.
Comment From: 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!
Comment From: spring-projects-issues
Rossen Stoyanchev commented
Almost forgot to mention. STOMP does support binary data payloads.
Comment From: 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.
Comment From: rstoyanchev
Closing as we have no plans to add this.