af_unix <-> af_inet proxy klib

[rinor]

With Nanos capabilities and compatibility evolving, the range of applications that can be run on Nanos is expanding quickly.

Now there are some applications, that for different reasons, speed, security (debatable in some cases), simplicity of the communication protocol, expose some core funtionality only through ipc/uds unix sockets and expect other applications that need to communicate, to get hold to that socket one way or another, by running on the same host, or by using tunnels (ssh, other) to expose that socket remotely. As there is no shared memory usage/need involved, the correct funtionality is not affected.

At the current state, there is no way to use this type of applications on Nanos, even though they run and function correctly, just because there is no way to get hold of that socket outside/remotely.

Is there any plan/request in place to implement such functionality?

[eyberg]

we've dealt with this in a variety of ways in the past mainly through patches (eg: wg) - do you have a concrete example (like a specific app) that you are running into ?

[rinor]

I understand, thanks. I was just curious, trying to understand if there was/is enough demand for this feature to justify the planning/implementation in the future, beyond case by case patches.

---

Just for context, not that we need to patch/do anything:

do you have a concrete example (like a specific app) that you are running into

From time to time, I test different DLT (Distributed Ledger Technology) based applications, atm for no other reason than simply testing Nanos stability/correctness. Right now I'm testing cardano-node that already helped expose some Nanos "possible issues" (some already fixed, some under investigation). The unix socket exposed there is very important and used for several purposes (administrative/management/monitor/...). Even the official docs, in some cases, explain in detail the tunneling configurations you need in place to communicate within the ecosystem. While that program can be patched, the "problem" is the ecosystem, because everything around that node is built upon that limitation/feature and expects a unix socket to be available somehow.

[eyberg]

I see. The vast majority of unix sockets are going to be in multi-process apps or entirely diff programs that are on the same machine so without looking into cardano specifically I don't know if a transparent bridge of sorts could work there or not as there could be other expectations that these individual processes expect to see. Having said that, to test it out without doing all the work for actually implementing this feature you could do a quick test with socat just to see if you run into other issues or not. If that test works then perhaps it's worth looking into more.

[rinor]

it should work. It's been some time since I worked with that environment, but in general this is what devs end up doing docker-compose.yml.

That said, just to be clear, I'm not asking for this to be implemented (at least not because of cardano, since cardano+nanos is not ready for production anyway, there are still some issues/edge cases kernel/fs related that cause unrecoverable data corruption)

[eyberg]

yeh - so they're using socat there - I think we could look at doing something like this eventually