You can continue to use unix domain sockets for communication between processes.
If the two processes are distributed as part of the same snap, then there is nothing special to do: they will both be able to read the same file system locations so one should be able to connect to the other’s listening socket.
If the two processes are from different snaps, things get a little more complicated due to sandbox restrictions. The
content interface is one way you can provide this communication channel. Roughly something like this:
- Have the server app create its listening socket in a directory under
- The server snap defines a content interface slot that provides read-only access to the above directory.
- The client snap defines a content interface plug with the
content: attribute matching that used by the above slot (or simply give the plug and slot the same name and omit the
- Have the client app connect to the socket in the location the plug mapped it to.
If the two snaps have the same publisher, the plug and slot should connect automatically on installation. If they differ, users will need to manually connect the two snaps. You can request a store assertion overriding this policy if there is good reason to expect the plug to automatically connect though.