search

ninjasource / embedded-websocket

A rust websocket library for embedded systems (no_std)
Apache License 2.0
98 stars 28 forks source link

Support MQTT sub-protocol #1

Closed hhamana closed 4 years ago

hhamana commented 4 years ago

I am currently writing a MQTT Client library for embedded, and would like to support delivery over Websocket. From my understanding, Websocket should then consider MQTT as a sub-protocol. In such use case, the connection would not go through HTTP at all. All documentation in embedded-websocket I've seen assumes HTTP first, including the automatic protocol upgrade, which would not happen in my case, as connection would be in MQTT from the start. The Client should not even support HTTP. Can you support such a use case?

ninjasource commented 4 years ago

Hi,

The HTTP upgrade is part of the websocket spec. See https://tools.ietf.org/html/rfc6455 If you are building an embedded MQTT client library then you would typically not use websockets at all. Websockets would normally be used if you want to use MQTT from a browser that does not support native TCP/IP connections (like most browsers today).

As an embedded client you may want to communicate with an MQTT broker that exposes the MQTT protocol over websockets rather than raw TCP/IP. If this is the case I would first look for an alternative endpoint that does not use a broker or use embedded-websocket to do the HTTP heavy lifting so your client library is free to send and receive raw bytes.

I hope that helps, David.

hhamana commented 4 years ago

Hmmm... seems the burden of supporting both protocols is only server side though? But I guess the client would need to connect with HTTP first before upgrading then. And yeah, you're right, typically it would just be over plain TCP/IP . MQTT by design kinda serves a similar usage of bilateral communication instead of request-based, so the benefit of using websocket is minor (really just the tunneling.) That's maybe too much unnecessary overhead on second thought, even though many implementations boast WS support. Oh well okay. Thank you. Feel free to close this issue.

Unrelated, if you want help testing on different boards, I'd be glad to help~

ninjasource commented 4 years ago

Hmmm... seems the burden of supporting both protocols is only server side though?

Looks that way. I would imagine that it is only used for browsers.

In your case websockets is only really useful for tunneling but that is sometimes the only way you can connect to a server. It's not such an overhead to be honest. Once the HTTP initiated handshake is complete the websocket protocol header is only 2 bytes in size for small messages. You would obviously not perform an opening handshake every time you send an MQTT message just like you wouldn't typically open a new TCP/IP connection every time you send a message either. Depends on the use case I guess.

Unrelated, if you want help testing on different boards, I'd be glad to help~

Thanks!