uSockets icon indicating copy to clipboard operation
uSockets copied to clipboard

add unix domain socket for both server and client side

Open Young-Flash opened this issue 3 years ago • 5 comments

First step to add unix domain socket support for uWebSockets. According to our previous discussion, this PR add unix sockets supports both server(listen) and client(connect) side, it also compiles successfully on Windows. Please let me know if there are somethings wrong you think, I am willing to make it better. @alexhultman

Young-Flash avatar Apr 18 '22 02:04 Young-Flash

As for SOCK_DGRAM over unix domain socket, it does not seem to support on Windows according to this blog. I am not sure whether it supports now, searched Google but could't find messages related to it.

Young-Flash avatar Apr 18 '22 05:04 Young-Flash

This PR is definitely not ready for merge but it is a good start.

https://devblogs.microsoft.com/commandline/af_unix-comes-to-windows/

The fact Windows now has Unix sockets means this could be a serious feature. It should be exposed with the exact interface as TCP though - SSL argument should be protocol and take UNIX, TCP, TLS, QUIC, HTTP3 and that's how the "transport" should be exposed to applications.

You don't have SSL over Unix sockets (makes no sense) so this works fine

ghost avatar Apr 18 '22 07:04 ghost

Sorry I can not understand well. Can you be more specific about what changes should I need to make? Do you mean us_socket_context_listen_unix and us_socket_context_connect_unix need't take the int ssl argument?

Young-Flash avatar Apr 18 '22 08:04 Young-Flash

Or don't add interfaces for unix domain socket listen and connect, just used the old TCP listen and connect interfaces and make some judgment inside according the given parameters to identify work over TCP or unix domain socket? @alexhultman

Young-Flash avatar Apr 27 '22 07:04 Young-Flash

The idea is to have only one interface and switch behavior based on protocol argument. You should be able to write an application for TCP, then configure it for TLS or Unix socket or even quic

ghost avatar Apr 27 '22 10:04 ghost

I would argue that SSL should stay separate from the choice to use IP/UNIX domain socket. It may not make sense in most use cases, but it is possible that someone will want ssl over a unix domain socket (Eg. some form of load balancer without ssl termination, etc...). Also, the functions require different parameters. A port is unnecessary for a domain socket, and in us_socket_context_connect, source_addr is also unnecessary. It's much more clear to have extra functions with _unix than have extra parameters that aren't used which will increase confusion during development. IMO, this should be good to merge (after conflicts are resolved). Thoughts?

glingy avatar Sep 07 '22 15:09 glingy

This PR is still a mess - it comments out code (which breaks current tests) and other things. Please fix that by building two versions of hammer_test one for TCP and one for Unix socket, etc.

uNetworkingAB avatar Sep 24 '22 20:09 uNetworkingAB

I update this pr, you can take a review when you are free

Young-Flash avatar Sep 25 '22 13:09 Young-Flash

Seems to work well on all platforms 👍

uNetworkingAB avatar Sep 25 '22 17:09 uNetworkingAB

I'd like to make a PR for uWebSockets to add the feature that run websocket over unix domain socket, add a interface TemplatedApp &&listen_unix(std::string path, int options, MoveOnlyFunction<void(us_listen_socket_t *)> &&handler), what do you think ?

Young-Flash avatar Sep 26 '22 02:09 Young-Flash

I would agree that’s a good idea.

glingy avatar Sep 26 '22 02:09 glingy

Go ahead 👍

uNetworkingAB avatar Sep 26 '22 12:09 uNetworkingAB

But I would call it listen and rely on overloading.

uNetworkingAB avatar Sep 26 '22 12:09 uNetworkingAB

got it

Young-Flash avatar Sep 26 '22 13:09 Young-Flash