StreamTubeServer doesn't support exporting services listening only on an Unix socket
Submitted by Olli Salli @oggis
Assigned to Telepathy bugs list
Description
Probably not very big of a problem, which is why we're merging STS although it has this limitation. The API has sufficient flexibility, though, to allow adding Unix socket support later.
Reasons it was left out originally:
- TCP sockets allow us to more conveniently associate ongoing connections with the remote contacts they're from as long as the CM supports Socket_Access_Control_Port (gabble does), as there are only so many (256) different 8-bit credential byte values for Unix, and credential bytes can't be even used with all protocols as they are in-line with the protocol bytestream
- I don't know of any services which couldn't be configured to also listen on TCP. X11 and cups can be, for example - so they're likely to be exported as TCP services due to the above limitation with connection monitoring
- The spec only requires CMs to support TCPv4 sockets too. Gabble supports all the address types anyway though.
Reasons why it would still be nice to have one day:
- Maybe better performance than TCP sockets for the same service? Dunno how much better, or if at all on practical systems.
- Credentials AC allows restricting the processes allowed to connect to those from the same UID (like our protocol backend), without explicitly authenticating using the tube payload protocol
- After all, some services might be really Unix only. At least X11 is in its usual distro configs (-nolisten tcp) and it's a bit crappy to have to change that.
Version: git master