Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.
And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.
MQTT over TCP as an optional transport
See original GitHub issueYou want to:
- report a bug
- request a feature
Status quo
“Transport” only supports ['polling', 'websocket']
Expected implementation
“Transport” supports ['polling', 'websocket', 'mqtt']
Rationale
When developing mobile apps (aka non-web), MQTT over TCP performs much better than HTTP (polling, websocket, or MQTT over websocket), however, like the adoption of websocket, MQTT over TCP might be stopped by firewall. In an ideal scenario, app developers should not care about the transportation, but focus on the logic. Transportation layer should gracefully chooses the best method, given the conditions. Ref https://www.quora.com/Is-MQTT-better-than-HTTP-for-mobile-app-iOS-Android-etc-client-server-communication
Other information:
- If this issue is approved, I can research how to optionally use https://github.com/mqttjs/MQTT.js as one of the transport method, e.g
['polling', 'websocket', require('mqtt-engine')]
Issue Analytics
- State:
- Created 7 years ago
- Comments:5 (2 by maintainers)
Top Results From Across the Web
Top Related Medium Post
Top Related StackOverflow Question
Troubleshoot Live Code
Top Related Reddit Thread
Top Related Hackernoon Post
Top Related Tweet
Top Related Dev.to Post
Top Related Hashnode Post
@hearsh I’m afraid no work has been done on our side yet, I don’t know if @truongsinh has had some time to dedicate to it.
Hi @truongsinh, sorry for the delay! That indeed looks promising, I’ll be happy to merge your pull request for that feature.
I’m afraid you’ll have to dig a bit into engine.io internals though 💪