Support for Multiple Endpoints

[vazois]

This PR adds support for multiple endpoints through --bind option.

[prvyk]

You can use several different loopback addresses together for the test and skip dealing with Dns/network interfaces. IPv4 has the entire 127.x.x.x range for this.

[vazois]

You can use several different loopback addresses together for the test and skip dealing with Dns/network interfaces. IPv4 has the entire 127.x.x.x range for this.

Thanks for the suggestion. I want to test also the non-loopback addresses. So, added test for loopback ipv4 and ipv6

[Copilot]

Pull Request Overview

This PR adds support for multiple endpoints through the --bind option by refactoring various modules to work with endpoint arrays instead of a single endpoint. Key changes include updating the configuration and validation functions (e.g. in Format.cs and Options.cs), adapting server initializations (e.g. in GarnetServer and StoreWrapper), and modifying test cases to use endpoint arrays.

Reviewed Changes

Copilot reviewed 18 out of 18 changed files in this pull request and generated 2 comments.

Show a summary per file

File	Description
test/Garnet.test/GarnetServerConfigTests.cs	Adds a new test to validate multi-endpoint support.
libs/common/Format.cs	Refactors endpoint parsing functions to return arrays and updates error messaging.
libs/server/Metrics/Info/GarnetInfoMetrics.cs	Adjusts metrics retrieval to support multiple endpoints.
libs/host/Configuration/OptionsValidators.cs, Options.cs	Updates configuration options for multiple endpoints.
test/Garnet.test/TestUtils.cs	Updates test utilities to work with endpoint arrays.
libs/server/Resp/PurgeBPCommand.cs, libs/server/Servers/ServerOptions.cs, libs/cluster/Server/...	Various updates to replace single endpoint properties with endpoint arrays.
test/Garnet.test/UnixSocketTests.cs, GarnetClientTests.cs, benchmark/...	Adjusts tests and benchmarks to align with multi-endpoint changes.

[prvyk]

This all works, just a few notes (IMHO it would be reasonable to save them for a future PR):

• Error message when failing to bind to an address is IMHO a bit worse now. Better to not print out the stacktrace by not passing the exception to LogError.
• RedisConf import currently uses only first bind address and does not yet support multiple endpoints.
• Redis allows creating a Unix socket concurrently. ('--bind 127.0.0.1 --unixsocket ./socket'. In Redis both are defined, here only the socket).

[vazois]

This all works, just a few notes (IMHO it would be reasonable to save them for a future PR):

• Error message when failing to bind to an address is IMHO a bit worse now. Better to not print out the stacktrace by not passing the exception to LogError.
• RedisConf import currently uses only first bind address and does not yet support multiple endpoints.
• Redis allows creating a Unix socket concurrently. ('--bind 127.0.0.1 --unixsocket ./socket'. In Redis both are defined, here only the socket).

I made a change to log the message instead of the stack trace for the first one.
Not 100% positive on this but the other two suggestions seem to require a little bit more work that might be better done at another PR. Especially the last one. I will check for the second one.

[badrishc]

Unix socket and TCP socket at the same time was, I thought, the use case that first drove this feature. Would be useful to see what makes that harder than two TCP sockets.

[vazois]

Unix socket and TCP socket at the same time was, I thought, the use case that first drove this feature. Would be useful to see what makes that harder than two TCP sockets.

The original purpose of this PR was to fully support hostnames that could map to multiple interfaces when provided through the bind option.
I am wondering if supporting unix sockets is as a simple as creating another instance of GarnetServerTcp.
If so, why we did not do this in the original PR? @PaulusParssinen

[badrishc]

I am wondering if supporting unix sockets is as a simple as creating another instance of GarnetServerTcp. If so, why we did not do this in the original PR? @PaulusParssinen

I think it should be as simple as creating another instance of GarnetServerTcp with that endpoint (@PaulusParssinen?) .. We did not support multiple GarnetServerTcp instances until this PR, so it was not done earlier, IIRC.

[PaulusParssinen]

I am wondering if supporting unix sockets is as a simple as creating another instance of GarnetServerTcp. If so, why we did not do this in the original PR? @PaulusParssinen

I think it should be as simple as creating another instance of GarnetServerTcp with that endpoint (@PaulusParssinen?) .. We did not support multiple GarnetServerTcp instances until this PR, so it was not done earlier, IIRC.

The reason I didn't try to do this all in one PR (the one that added support for unix socket) is that I don't have confident mental model for what sort of changes that could possibly entail and hoped that just like this PR does, someone who has much clearer picture of the cluster mode (and the current networking stack) would have stab at it instead (Thanks!).

Glad to see it was as simple as making many GarnetServerTcp instances 🎉

[TalZaccai]

Added some config-related comments...