uNetworking
Add support for already-listening sockets
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_direct hastily 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
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
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
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, any chance of merging soon? Afterwards, it will be straightforward to add an fd option to Bun's ServeOptions. (Note the similar feature request in Deno: https://github.com/denoland/deno/discussions/14008)
@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.