Evaluate node-to-client communication via TCP

[scarmuega]

The node-to-client mini-protocols are only available via unix-socket connections. AFAIK, the goal of this constraint is to reduce the attack surface, improving security.

Although valid, this approach limits the deployment options at the infrastructure level. A setup that includes Cardano Node, DBSync, Ogmios, Submit-API, etc forces the operator to merge the workload under a single host, which is far from ideal.

Allowing each component to run in a different hosts brings several benefits: horizontal scaling, high-availability, resource isolation, etc. Many operators from the community have relied on workarounds (eg: UNIX <=> TCP socat tunnels) to escape the constrained imposed by the Node.

On a private network topology, having a way to enable node-to-client communication via TCP would simplify configuration and introduce new deployment options. This option should be disabled by default and would require an explicit opt-in from the operator to enable it.

[dcoutts]

Yes the rationale is security by default.

The node can already listens on multiple sockets for the node to node protocol, e.g. for IPv4 and IPv6. It would not be terribly difficult to listen on multiple sockets for the node to client protocol, and those can be any appropriate socket (unix domain, tcp ipv4, tcp ipv6). It would also need changes to the configuration handling, to be able to specify.