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

Guido van Rossum guido at python.org
Thu Jan 24 19:23:40 CET 2013


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)



More information about the Python-ideas mailing list