swift-server
Use sockaddr structure instead of port for connection address
From comments by @helje5 in #81
Port is insufficient. We need to allow an (or many!) arbitrary sockaddr_in (either via sockaddr_in or a wrapper). If only to allow IPv6 and such. af_local is very useful too.
See #81 for more comments:
Helge:
I think it is more important to not use a plain port, but a sockaddr. Because the same way like you want to do wildcard ports, you want to do wildcard addresses, or not, or different addresses. (not wanting to do non-wildcard addresses seems even more important than wildcard ports to me - aka bind to specific server interfaces)
I have a small set of extensions for the Posix that make them really easy to use as-is (wildcard binding, address binding, all that). Feel free to integrate them:
https://github.com/NozeIO/Noze.io/blob/master/Sources/net/SocketAddress.swift#L27
Chris B:
Agreed - we definitely need support for full addresses to be passed in via Options.
Wouldn't the networking part of this working group provide an abstraction over sockaddr_in that the HTTP part would use? I don't think it's a good idea to vend C types in public API?
Wouldn't the networking part of this working group provide an abstraction.
Yes, but it seems we are further along? Once they have something, we should switch to it. Or they just adopt what we do. Is someone actually working on this?
I don't think it's a good idea to vend C types in public API?
I don't see a particular issue with using C system types. However, the specific case of sockaddr is indeed more problematic because it is a variable sized structure, not really suitable to be passed around in Swift.
Which is why I also use a sockaddr_any: https://github.com/NozeIO/Noze.io/blob/master/Sources/xsys/sockaddr_any.swift#L17
Anyways: the gist of this is that we need to be able to pass in socket addresses. Whether using sockaddr or something else doesn't matter a lot to me.
Another idea: URL might be a suitable option which would allow you to pass in IPv6, IPv4 and AF_LOCAL (file://) addresses. A little weird, but maybe not that much.
The only thing, would wildcards pass a URL? (http://*:*/ or http://127.0.0.1:* etc) Hm.
Mildly related, Envoy uses tcp:// for some of its specifications: https://github.com/envoyproxy/envoy/blob/master/docs/configuration/listeners/listeners.rst
Hm, right, they use 0 for wildcard. Which I guess works, but nice is different ;->