On 12:57 pm, twisted-...@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 _______________________________________________ Twisted-Python mailing list Twisted-Python@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
