Add support for Unix-domain sockets

[fpagliughi]

I'd like to add support for Unix-domain sockets.

These satisfy the MQTT v5 transport requirement for "ordered, lossless, [bidirectional] stream of bytes", but on a local machine, they provide higher throughput with lower latency and increased security in comparison to TCP.

A great use case for MQTT is providing an internal message bus on a remote device or computer, in which a large percentage of the messages are simply passed around inside the local machine. The use of MQTT for this is particularly helpful in IoT gateways where some subset of the messages are then bridged to a cloud server in a more traditional MQTT usage. But using UNIX sockets for the internal communications would make them faster and safer.

I have long rallied for this feature to be added to Mosquitto based on the performance metrics, to no avail. But Roger finally relented based on the security argument:

The main reason that I changed my mind on this was the idea of having localhost only listener, where the access control was through the socket permissions. It's much easier to isolate a trusted listener that way.
eclipse/mosquitto#467

I would suggest for the Paho Client(s) we use a URL in the form:

unix://path/to/socket

whereas if it's an absolute path, use the additional slash:

unix:///absolute/path/to/socket

And my biggest hope is that this is actually pretty trivial to implement in the client. Once opened, a Unix socket should mostly just behave as a socket.

[icraggs]

I thought about this a long time ago, and I seem to remember implementing at least a trial. I think, one of the reasons that it hasn't been done so far is that it isn't quite as straightforward as one would hope. I would be happy to be proved wrong in that, but I wouldn't be surprised either way.

When you say "I'd like to add" ... does that mean you are considering a PR? :-)

[fpagliughi]

You might have noticed my "once opened" caveat. Sometimes permissions and security issues trip you up to make a connection, but they're usually well behaved once running. But I was throwing this out to see if anyone could think of any other problems.

And I suppose that I am "considering" a PR. But I have a release of the Rust library to push out this week, then the C++ service release, and then a bigger update on the Rust lib to get it up to "modern" Rust standards.

So if anyone beat me to this, I wouldn't be (a) surprised, or (b) offended.

[pulquero]

Came across this for the python client https://pypi.org/project/paho-socket/. Might be a stop-gap for some of us while we are waiting on this issue.

[vjardinMisc]

Hi,

I don't see any merge request, is anything ongoing? If not, I'll try to submit a AF_UNIX case.

[icraggs]

I'm not aware of any current work on this, no.

[fpagliughi]

Sorry, I haven't have any time to get started on this. I would still love to see it get done, so if anyone else wants to get to it before I have the time, please do so, and I will be happy to review and test.