Skip to content
This repository has been archived by the owner on Nov 23, 2021. It is now read-only.

Use sockaddr structure instead of port for connection address #89

Open
gtaban opened this issue Nov 8, 2017 · 6 comments
Open

Use sockaddr structure instead of port for connection address #89

gtaban opened this issue Nov 8, 2017 · 6 comments

Comments

@gtaban
Copy link
Collaborator

gtaban commented Nov 8, 2017

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.

@gtaban
Copy link
Collaborator Author

gtaban commented Nov 8, 2017

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.

@ianpartridge
Copy link
Contributor

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?

@helje5
Copy link
Contributor

helje5 commented Nov 8, 2017

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.

@helje5
Copy link
Contributor

helje5 commented Nov 8, 2017

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.

@ddunbar
Copy link

ddunbar commented Nov 8, 2017

Mildly related, Envoy uses tcp:// for some of its specifications:
https://github.com/envoyproxy/envoy/blob/master/docs/configuration/listeners/listeners.rst

@helje5
Copy link
Contributor

helje5 commented Nov 8, 2017

Hm, right, they use 0 for wildcard. Which I guess works, but nice is different ;->

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants