[Twisted-Python] Setting socket options before connect
exarkun at twistedmatrix.com
exarkun at twistedmatrix.com
Mon Jul 15 05:44:08 MDT 2013
On 01:01 am, glyph at twistedmatrix.com wrote:
>
>On Jul 12, 2013, at 5:09 AM, exarkun at twistedmatrix.com wrote:
>>On 10:42 am, p.mayers at imperial.ac.uk wrote:
>>>On 12/07/13 11:34, Itamar Turner-Trauring wrote:
>>>>Subclass twisted.internet.tcp.Client, override
>>>>createInternetSocket() so
>>>>it calls setsockopt() on the socket after you've called base
>>>>implementation to create it. This breaks some abstraction
>>>>boundaries, so
>>>>it isn't great, but very little code duplication is involved.
>>>
>>>Ah, ok. Presumably I also need to subclass Connector and override
>>>_makeTransport to use MyClient, then call MyConnector() directly (or
>>>subclass the reactor... shudder)
>>>
>>>Should there be something built in to Twisted for this? Should I open
>>>a ticket?
>>
>>If you want your code to keep working, or to work with alternate
>>reactor implementations, then you'd *really* rather use a documented,
>>tested interface rather than the hack outlined above.
>
>Does such an API exist today, or should a ticket be filed for one?
Hm, I'm not *totally* sure what you mean.
There's the approach Itamar outlined, using APIs such as
`twisted.internet.tcp.{Client,Server}`. I don't think we should codify
this as the public, stable, encouraged API to use - for precisely the
reasons you give below.
There's various other APIs that are clearly related but definitely don't
currently allow you to wedge this functionality in:
1) reactor.connectTCP - nowhere to pass extra socket options now, but
we could add more arguments to it I suppose. Doesn't sound very nice to
me.
2) endpoints? Again, no current support, but it's a place you could
add new parameters. Of course, this isn't a complete solution, since
endpoints mostly just use reactor methods to set things up - but if we
had a nice endpoints-based API then we could have a gross lower-level
API that no one actually has to use. Still, is
"tcp:host=A:port=B:sockopt=TCP_CORK|TCP_QUICKACK" the road we want to go
down?
3) More transport methods - but this is an incomplete solution, as
certain sockopts only make sense before a connection, so once you have a
transport it's too late.
Maybe someone else has some suggestions from a totally different
ballpark that solve the problem more pleasantly?
Anyhow, I think this certainly means a ticket should be filed for
introducing some API - but it seems that a little more discussion about
what the API should be will still be necessary.
Jean-Paul
>For everyone's information, in case it's not entirely clear from the
>documentation resources available: we hope to eventually deprecate the
>whole 'tcp' module so that people (myself included ;-)) stop
>subclassing stuff in it, so writing new code that depends on this, even
>the nominally "public" parts of the API (the bits without underscores)
>would be really unfortunate. If we can figure out something that uses
>totally public APIs without subclassing tcp.Client that would be best;
>if not, we should really have a ticket open to fix the API so that it
>is possible.
>
>-glyph
More information about the Twisted-Python
mailing list