Some years ago I started working on a patch for the socket module which added a couple of utility functions for being able to easily create a server socket, with the addition of being able to accept both IPv4 and IPv6 connections (as a single socket): https://bugs.python.org/issue17561
Given that not all OSes (Windows, many UNIXes) support this natively, I later submitted a recipe adding a "multiple socket listener" class. https://code.activestate.com/recipes/578504-server-supporting-ipv4-and-ipv6/ >From the user perspective, the whole thing can be summarized as follows: >>> sock = create_server_sock(("", 8000)) >>> if not has_dual_stack(sock): ... sock.close() ... sock = MultipleSocketsListener([("0.0.0.0", 8000), ("::", 8000)]) >>> Part of this work ended up being included into Tulip internals: https://github.com/python/cpython/blob/70d28a184c42d107cc8c69a95aa52a4469e7929c/Lib/asyncio/base_events.py#L966-L1067 ...and after that I basically forgot about the original patch. The other day I bumped into a case where I needed exactly this (on Windows), so here I am, trying to revamp the original proposal. To be clear, the proposal is to add 3 new APIs in order to avoid the low-level cruft needed when creating a server socket (SO_REUSEADDR, getaddrinfo() etc.) and being able to support IPv4/6 dual-stack socket servers in a cross-platform fashion: - socket.has_dual_stack() - socket.create_server_sock() - socket.MultipleSocketsListener Whereas the first two functions are relatively straightforward, MultipleSocketsListener is more debatable because, for instance, it's not clear what methods like getsockname() should return (because there are 2 sockets involved). One possible solution is to *not* expose such (all get*?) methods and simply expose the underlying socket objects as in: >>> socket.MultipleSocketsListener(...).socks[0].getsockname() On the other hand, all set* / write methods (setblocking(), setsockopt(), shutdown(), ...) can be exposed and internally they can simply operate against both sockets. Thoughts? -- Giampaolo - http://grodola.blogspot.com
_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/