Add support for already-listening sockets #192
Conversation
Adds `us_socket_context_listen_direct`, which takes a socket rather than a port or a path to a UNIX socket.
This would be nice. The user or API one layer up would need to ensure that the file descriptor isn't already being polled by the current epoll or else it would cause strange behavior, but that's fine |
|
Smart, will have a look when I have time |
|
It looks small 👍 |
Simple showcase of passing a socket into a restricted Linux network namespace.
|
Yup, just a matter of naming and sanitizing a long-term interface. I added a small example of how this would be used with network namespaces. |
uNetworkingAB
force-pushed
the
master
branch
4 times, most recently
from
3bc1f9d to
d29d5ba
Compare
|
@uNetworkingAB, any chance of merging soon? Afterwards, it will be straightforward to add an |
|
@e3dio , I tested systemd socket activation with the entire stack of changes to Bun and uSockets, since that was the purpose of the PRs. But in the last year, some minor conflicts have arisen. I don’t have time to resolve them right now, but feel free to pick up where I left off. |
3 participants
Background. It's often desirable to work off a given listening fd, rather than opening a port or UNIX domain socket. For example, a listening FD can be passed from a process in a global network namespace to a server in a restricted namespace, for security/isolation. In systemd socket activation, the externally-facing network or domain socket is bound and listened by systemd. When a new connection arrives, the service is started with the socket descriptor passed as an int in the LISTEN_FDS environment variable.
Implementation.
us_socket_context_listen_directhastily added without tests or examples. Should probably be renamed, since it takes a listening socket, but doesn't call listen() itself. Just want to get this ball rolling, in the hopes that this mode is eventually supported by Bun. With node, it's possible to run servers directly in this manner. cc @Jarred-Sumner