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

[Guido van Rossum]

On Thu, Jan 24, 2013 at 11:05 AM, Nikolay Kim <fafhrd91 at gmail.com> wrote:
>
> 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.

Aha, that makes some sense. Though maybe it shouldn't be a dict -- it
may be expensive to populate some values in some cases, so maybe there
should just be a method transport.get_extra_info('key') which computes
and returns (and possibly caches) certain values but returns None if
the info is not supported. E.g. get_extra_info('name'),
get_extra_info('peer'). This API makes it pretty clear that the caller
should check the value for None before using it.

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