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

[Nikolay Kim]

On Jan 24, 2013, at 10:50 AM, Guido van Rossum <guido at python.org> wrote:

> On Thu, Jan 24, 2013 at 10:45 AM, Yuval Greenfield
> <ubershmekel at gmail.com> wrote:
>> On Thu, Jan 24, 2013 at 8: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.
>> 
>> 
>> I feel (A) is the best option as it's the most flexible - underlying
>> transports can have many different special methods. No?
> 
> The whole idea of defining a transport API is that the protocol
> shouldn't care about what type of transport it is being used with. The
> example of using an http client protocol with a subprocess transport
> that invokes some kind of tunneling process might clarify this. So I
> would like the transport API to be both small and fixed, rather than
> having different transports have different extensions to the standard
> transport API.
> 
> What other things might you want to do with the socket besides calling
> getpeername() or getsockname()? Would that be reasonable to expect
> from a protocol written to be independent of the specific transport
> type?

transport could have dictionary attribute where it can store optional information
like socket name, peer name or file path, etc.