[Twisted-Python] Setting socket options before connect

[exarkun at twistedmatrix.com]

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