[Twisted-Python] What is the minimum effort solution to make inetd-managed twisted-based application?
exarkun at twistedmatrix.com
exarkun at twistedmatrix.com
Tue Jul 13 10:37:08 EDT 2010
On 12:57 pm, twisted-web at udmvt.ru wrote:
>What is the minimal effort method for building protocol instance (maybe
>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
>suppose, we have protocol (and factory) already implemented, but
>how to construct the correct transport out of fd with the minimal
>Or how to implement ucspi-tcp's tcpclient client on top of twisted
>Right now I am looking at t.i.unix.Connector and t.i.unix.Port to
>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
>(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
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
>implementation, as I need. Is it true, that nobody in twisted community
>anonymous preconnected sockets in real life?
>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! :)
More information about the Twisted-Python