You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Right, there are two issues here: (1) what we should be doing with IPV6_V6ONLY by default (which overlaps with #72), and (2) fixing the exception.
Am I reading your table correctly as saying that the problem happens when you set up a listen socket with IPV6_V6ONLY set to False, then accept a v4 connection, and then trio tries to set IPV6_V6ONLY on the new labeled-as-ipv6-but-secretly-actually-a-v4-socket? That makes a lot of sense :-). So at the very least we should tolerate an error here.
As to the larger question of defaults, there are a few competing considerations:
The problem with accepting the system default is that it leads to non-portable programs (in particular in this case: test on linux, everything works fine because in fact everyone leaves bindv6only set to 0, and then you're broken on windows because they make IPV6_V6ONLY default to enabled. And in practice, setting V6ONLY=False doesn't actually make programs magically handle ipv4 and ipv6 equally, because e.g. people expect that their web server's connection logs will contain ipv4 addresses rather than ipv6-mapped-ipv4 addresses. So I figured better to have consistency and then let people pick if they want something different... libuv does something similar, though IIRC they have the opposite default from trio's current setting. I don't have a strong opinion on which default is better :-)
But then there's another issue: initially I hoped that trio.socket would be the standard user-level API for doing networking in trio, but in the course of implementing SSL support have come around to the conclusion that we need a higher-level layer that provides a dedicated "stream" abstraction. There's a huge work-in-progress branch in #107 with the initial part of this. As part of this, I've defined a SocketStream class that adapts a socket into the Stream interface; and probably I will also add high-level helpers for connecting to a host+port and for listening on a port, that are defined at this level. So... if trio.socket is becoming the "low-level raw" networking API, maybe it does make more sense to remove the default-setting code from here, and instead handle it in the higher-level layer. (So in particular, the "listen on this port" interface would automatically create both ipv4 and and ipv6 sockets, and transparently listen on both of them.)