search

redboltz / mqtt_cpp

Boost Software License 1.0
432 stars 107 forks source link

Support Unix Domain Sockets for connectivity #932

Open zinzila opened 2 years ago

zinzila commented 2 years ago

Using UDS can be beneficial for local deployments of the client and a broker. It should have better performance and will provide additional security for such scenarios.

Support for unix domain sockets was added to Mosquitto some time ago: https://github.com/eclipse/mosquitto/pull/1522

redboltz commented 2 years ago

I investigated a litte about Unix Domain Scokets. Boost.Asio support it. See https://www.boost.org/doc/libs/1_79_0/doc/html/boost_asio/reference/local__stream_protocol/socket.html

I guess that mqtt_cpp can work with this.

Now, I'm working on re-design endpoint for faster speed and smaller memory consumption on compile time. So I don't have much time. But I will support Unix Domain Scokets in the future.

ineffective commented 1 year ago

I believe that when you get around to it you could investigate whether other types of streams could be supported in a generic manner. Quite probably this could be done by an ability to pass any freshly opened socket/stream to the mqtt client (and/or server). This is an interesting feature because not only local_stream could be used aside from classic sockets, but also async_pipe and maybe other mechanisms.

Also note that on Linux/Unix (not on Windows, where local sockets are supported but in a limited way) unix sockets allow for getting uid (UserId) of the process that opened other side of the connection. I do it in my services to allow only services with specific uid to connect, and then to limit where they can send messages - e.g. some services can send only local messages, others can send only to the remote mqtt server and others can send messages anywhere.