Add Unix socket support

[PaulusParssinen]

This PR adds initial unix socket support to Garnet. The unix domain socket path can be specified with --unixsocket switch. Because string address, int port pair was used everywhere, this change required a lot of tiny changes in testing and networking logic. There is more clean-up work left in some parts of the code, e.g. using IPEndPoint to represent cluster nodes instead of the (string address, int port) tuple.

I'm leaving implementation of --unixsocketperm switch to be done as a follow-up. --unixsocketperm is now implemented for applicable platforms.

I'm also for now making the server initialization throw NotImplementedException if user attempts to specify unix socket listener in cluster mode. Supporting cluster mode would need bit more work to have two different types of listener endpoints active.

Contributes to #682

[vazois]

Nice work! Going through it in iterations because it changes a lot of files.
Are we adding any explicit tests for unix socket?

[PaulusParssinen]

Are we adding any explicit tests for unix socket?

I added single, a very primitive, test to check that the networking stacks of server and GarnetClient behave normally with unix socket endpoint here.

If you have any ideas for further tests, I'm happy to add them.

[vazois]

Are we adding any explicit tests for unix socket?

I added single, a very primitive, test to check that the networking stacks of server and GarnetClient behave normally with unix socket endpoint here.

If you have any ideas for further tests, I'm happy to add them.

Perfect, this is exactly what I was looking for. I am wondering if having also the same but with TLS on would make sense or if it is even possible. If you can add something like that, it will be great.

[badrishc]

I'm leaving implementation of --unixsocketperm switch to be done as a follow-up

this would be nice to have as part of unix socket support. separate PR is fine if it is a non-trivial addition.

[badrishc]

Hi @PaulusParssinen, when the unix socket is enabled, does that need to preclude normal TCP listeners and connections to the server? It seems we ought to be able to accept both (or just one if so desired) at the same time, i.e. enabling unix sockets should not preclude TCP connections. That way cluster mode would continue to work (using TCP, because cluster is usually remote servers) when unix sockets are enabled.

E.g., in other systems, you would enable both endpoints as follows:

port 6379
unixsocket /tmp/redis.sock

[PaulusParssinen]

Perfect, this is exactly what I was looking for. I am wondering if having also the same but with TLS on would make sense or if it is even possible. If you can add something like that, it will be great.

You're right, I think TLS path needs to be tested (or atleast how it fails and handle that if it is trivial to support ). I'll investigate 👍

I'm leaving implementation of --unixsocketperm switch to be done as a follow-up

this would be nice to have as part of unix socket support. separate PR is fine if it is a non-trivial addition.

Should be pretty trivial in hindsight, if we presumably gate this permission option for non-windows platforms 👍 (unless someone knows how to map unix permission octal to windows file permission!)

Hi @PaulusParssinen, when the unix socket is enabled, does that need to preclude normal TCP listeners and connections to the server? It seems we ought to be able to accept both (or just one if so desired) at the same time, i.e. enabling unix sockets should not preclude TCP connections. That way cluster mode would continue to work (using TCP, because cluster is usually remote servers) when unix sockets are enabled.

Originally I wrote in the PR description, to currently to keep the PR "simple", to make it temporarily either or decision => inherently makes cluster-mode not supported. This made the PR mostly mechanical (string ip, int port) tuple to EndPoint abstraction change, which just almost automatically brings unix domain socket support to the application (just needs config parsing).

This of course does not need to be case, but having two listener endpoints active (it'd be probably implemented to support any number of endpoints) from my viewpoint would singificantly raise the complexity of this PR as I think I'd have to spend quite bit more time to be confident to start refactoring the networking stack to accommodate this (potential races etc.). That's my rational for why I'd rather see this work be done as a follow up PR. This PR lays foundation for this follow-up refactor imo.

[badrishc]

This of course does not need to be case, but having two listener endpoints active (it'd be probably implemented to support any number of endpoints) from my viewpoint would singificantly raise the complexity of this PR

This makes sense. Now that we have the clean abstraction of endpoints, the introduction of multiple endpoints should be doable as a separate work item, as that is orthogonal to this PR.