[Python-ideas] PEP 3156: getting the socket or peer name from the transport

Thu Jan 24 20:34:06 CET 2013

On 2013年1月24日 10:23:40 -0800
Guido van Rossum <guido at python.org> wrote:
> A pragmatic question popped up: sometimes the protocol would like to
> know the name of the socket or its peer, i.e. call getsockname() or
> getpeername() on the underlying socket. (I can imagine wanting to log
> this, or do some kind of IP address blocking.)
>> What should the interface for this look like? I can think of several ways:
>> A) An API to return the underlying socket, if there is one. (In the
> case of a stack of transports and protocols there may not be one, so
> it may return None.) Downside is that it requires the transport to use
> sockets -- if it were to use some native Windows API there might not
> be a socket object even though there might be an IP connection with
> easily-accessible address and peer.

I don't understand why you say Windows doesn't use sockets for IP
connections. AFAIK, sockets are the *only* way to do networking with
the Windows API. See e.g. WSARecv, which supports synchronous and
asynchronous operation:
http://msdn.microsoft.com/en-us/library/windows/desktop/ms741688%28v=vs.85%29.aspx
(I also suppose you meant "TCP connection", not "IP connection" ;-))
That said, the problem with returning a socket is that it's quite
low-level, and might return sockets with different characteristics
depending on the backend. So, while it can be there, I think the
preferred APIs for most uses should be B or C.
> C) Similar to (A) or (B), but putting the API in an abstract subclass
> of Transport (e.g. SocketTransport) so that a transport that doesn't
> have this doesn't need to implement dummy methods returning None -- it
> is now the protocol's responsibility to check for
> isinstance(transport, SocketTransport) before calling the method. I'm
> not so keen on this, Twisted has shown (IMO) that a deep hierarchy of
> interfaces or ABCs does not necessarily provide clarity.

IMO, Twisted mostly shows that zope.interface doesn't combine very well
with automated doc generators such as epydoc (you have to look up the
interface every time you want the documentation of one of the concrete
classes).
And as Ben says, I don't think you want to enumerate all possible
introspection APIs (such as the various pieces of SSL-related
information) on the base Transport class.
Regards
Antoine.