[Twisted-Python] Setting socket options before connect

[exarkun at twistedmatrix.com]

On 10:27 am, p.mayers at imperial.ac.uk wrote:
>On 17/07/13 18:44, Glyph wrote:
>>>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.
>>
>>Agreed.  But then, it's been a couple days and nobody else has
>>contributed to this thread :-).
>
>Well, since I started it...
>
>Some kind of endpoint argument might be problematic for some use-cases. 
>In particular, Twisted would have to know how to convert the argument 
>into the value to pass into setsockopt() and possibly in a platform- 
>specific way.
>
>The API as presented also omits the SOL.

It wasn't so much an API as a "Hey, I have an idea... endpoints... here 
is an example I can think of in 10 seconds." :)
>I guess it might be ok if there was a way to reliably inject unknown 
>options with arbitrary payloads, but I'm struggling to see a clean way 
>to do this with a "parse a string"-style API.

I think you're talking about the fact that "sockopts" are random 
integers associated with other big piles of random integers.  Some of 
them are flags you turn on, but some come with random payloads of 
basically no possible known shape.

It sounds like you're trying to think of an API that will support any 
and all socket options without understanding them.  This API exists 
already.  It is `setsockopt`.  There's no reason to re-invent it.

I prefer the approach taken elsewhere in Twisted, where a particular 
option is given some consideration and an API that understands the 
option is introduced.  This approach certainly has its shortcomings - 
for example, it doesn't support arbitrary options. :)  Do people really 
like using `setsockopt` though?
>
>So, vote me +0.5 for a "pre-connect" function.
>
>But but but...
>
>It might be possible to sidestep this entire issue by providing a clean 
>way for an app to inject itself "above" the socket. I can think of a 
>few use- cases for this, most notably things like cmsg/IP_HDRINCL which 
>Twisted doesn't know about, and thus can't handle.
>
>So maybe the correct way to handle this is "implement your own FD 
>object"?

Nothing stops anyone from doing this already, today.  Except that it's a 
lot of work and no one seems to want any of these features badly enough 
to do it.

Jean-Paul