Re: [Python-ideas] Add socket utilities for IPv4/6 dual-stack servers

[Victor Stinner]

Would it be possible to create a PyPI project to experiement the API and
wait until we collected enough user feedback first?

Currently socket is low level. Not sure if I like the idea of putting more
high level features in it? Asyncio is a good place for high level features,
but is limited to async programming.

Victor

Le 5 mars 2017 12:46, "Giampaolo Rodola'"  a écrit :

> 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/70d28a184c42d107cc8c69a95aa52a
> 4469e7929c/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/
>
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Add socket utilities for IPv4/6 dual-stack servers

[Giampaolo Rodola']

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/