add unix domain socket for both server and client side

[Young-Flash]

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]

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.

[ghost]

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

[Young-Flash]

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]

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

[ghost]

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

[glingy]

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?

[uNetworkingAB]

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.

[Young-Flash]

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

[uNetworkingAB]

Seems to work well on all platforms 👍

[Young-Flash]

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 ？

[glingy]

I would agree that’s a good idea.

[uNetworkingAB]

Go ahead 👍

[uNetworkingAB]

But I would call it listen and rely on overloading.

[Young-Flash]

got it