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

[Guido van Rossum]

On Thu, Jan 24, 2013 at 11:14 AM, Ben Darnell <ben at bendarnell.com> wrote:
> On Tornado we basically do A (the IOStream's socket attribute was never
> really documented for public consumption but has become the de facto
> standard way to get this kind of information).  As food for thought,
> consider extending this to include not just peer address but also SSL
> certificates.  Tornado's SSL support uses the stdlib's ssl.SSLSocket, so the
> certificate is available from the socket object, but Twisted (I believe)
> uses pycrypto and things work differently there.  To expose SSL certificates
> (and NPN, and other information that may or may not be there depending on
> SSL implementation) across both tornado- and twisted-based transports you'd
> need something like B or C.

Excellent points all. I'll mull this over -- it's unfortunate that (A)
is so easy to do and handles future needs as well, but may shut out
alternate transport implementations...

> -Ben
>
> On Thu, Jan 24, 2013 at 1:23 PM, 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.
>>
>> B) An API to get the address and peer address; e.g.
>> transport.getsockname() and transport.getpeername(). These would call
>> the corresponding call on the underlying socket, if there is one, or
>> return None otherwise; IP transports that don't use sockets would be
>> free to retrieve and return the requested information in a
>> platform-specific way. Note that the address may take different forms;
>> e.g. for AF_UNIX sockets it is a filename, so the protocol must be
>> prepared for different formats.
>>
>> 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.
>>
>> Discussion?
>>
>> --
>> --Guido van Rossum (python.org/~guido)
>> _______________________________________________
>> Python-ideas mailing list
>> Python-ideas at python.org
>> http://mail.python.org/mailman/listinfo/python-ideas
>
>



-- 
--Guido van Rossum (python.org/~guido)