[Twisted-Python] What is the minimum effort solution to make inetd-managed twisted-based application?

[exarkun at twistedmatrix.com]

On 12:57 pm, twisted-web at udmvt.ru wrote:
>What is the minimal effort method for building protocol instance (maybe 
>out of
>already implemented protocol factory) using a transport, that uses
>parent-inherited sockets (or any other already connected sockets) ?
>I haven't yet found any single-line solution for that.

This isn't supported, but we'd like to support it.  There's a ticket in 
the issue tracker, <http://twistedmatrix.com/trac/ticket/4387>, related 
to this (but with a somewhat wider scope).
>For example, how to start an inetd-managed SMTP server (with STARTTLS 
>support),
>suppose, we have protocol (and factory) already implemented, but
>how to construct the correct transport out of fd with the minimal 
>effort?
>
>Or how to implement ucspi-tcp's tcpclient client on top of twisted 
>framework?
>
>Right now I am looking at t.i.unix.Connector and t.i.unix.Port to 
>understand
>how do transports get constructed by them, but well, that is too 
>complex for a single evening.
>Should I really get into the details of implementing my own transport 
>(or their constructors)
>to do what I need? I'm sure there should be something, that I missed in 
>the documentation
>(or in the code?).

Despite not appearing to be private, things like t.i.unix.Connector and 
t.i.unix.Port aren't really intended for use by applications.

This is the right part of Twisted to be looking at if you want to 
contribute a patch which adds this feature, though.  And I encourage you 
to do that. :)

The implementation should be fairly straight-forward.  Most things like 
Port and Client and Server have a "createInternetSocket" method.  All 
that's really necessary to use an externally created file descriptor is 
get "createInternetSocket" to return that descriptor instead of creating 
a new one (or skip the call to the method entirely and just use the 
descriptor you have already).

The biggest question I have is what the API should look like.  Somehow 
the file descriptor needs to get from your application code (which knows 
that inetd put an open TCP connection on fd 0) to the 
Port/Client/Server.

The obvious options, adding another argument to 
listen/connectTCP/UNIX/etc, would work, but is somewhat ugly (you have 
the issue that existing mandatory arguments would just be ignored).

Another idea would be adding new methods entirely.  I don't know if 
that's much better, though.

So, if we can come up with a nice API, I think this will be a pretty 
quick feature to implement.
>And by the way, I haven't found any socketpair(2) usage in the twisted 
>framework (except for tests),
>how can that be? Transport based on socketpair sockets will have the 
>same
>implementation, as I need. Is it true, that nobody in twisted community 
>uses
>anonymous preconnected sockets in real life?

Apparently. :)
>
>PS: I need socket-based transport, that is, full-duplex, half- 
>closeable, with support
>of getting the remote endpoint address and with ability to start TLS on 
>top of it
>and without implementing every that feature myself :)

Hopefully if we can figure out how to create a Twisted transport object 
from an existing file descriptor, you should have no trouble with the 
rest of these.
>Thanks for a great framework!

You're welcome, and thanks! :)

Jean-Paul