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

[Alexey]

On Wed, Jul 14, 2010 at 02:31:46AM -0000, exarkun at twistedmatrix.com wrote:
> I'll answer whatever questions I can. :)

Oh, I have some questions...
I asked some questions in the form of suggestions, well, don't take them seriously,
I only ask, not really propose anything. However I'm ready to hear you
about what I'm wrong with.

Here, what I have discovered so far:
There are transport factories in twisted, not defined as such, but really they are,
like tcp.Port and tcp.Connector.

They interface with protocol factories. That interface is asymmetric between
server protocol factory and client protocol factory. Well, the implementation
of client's side protocol factory and server's side should differ, but why should interfaces?
That is okay, while you only have different and asymmetric transport factories
the ones for client transports and the others for server transports.
But is there really something in created and connected transport,
that makes it server's or client's ? I guess nothing, except protocol instance attached.

Q: Why should protocol factory interface "bother" about client/server dichotomy?
For example, why should I be limited to only using PBClientFactory with connectXXX()
variants of transport factories?
Why should I do not want (under some crazy circumstances) to use reverse-connects
and run PBServerFactory with connectXXX()?
Well, maybe not PB, but what about other protocols?
Should it work? Well, I suppose, it would break if you try now, but is
is supposed to be that asymmetric?

And after all, there is absolute symmetry in UDP-based transports.

Q: Consider socketpair() variant - a pair of completely symmetric mutually
connected sockets.
Should I provide transport factory for use with server protocol factories
and another transport factory for use with client protocol factories?

That idea sounds stupid to me, there can be no difference in the implementation,
except in the interfaces to protocol factories.

I see there are some code, that can be moved from tcp.Port and tcp.Connector
to some common base class of an abstract transport factory. That class could
interfere with protocol factory without knowing whether it is server or client.
Protocol factory already knows about it's own asymmetry.

I do identify the events, that protocol factory receives from transport factory as these,
please correct me if I'm wrong:

global (factory-context) events:
- start factory                         doStart
- entering transport creation phase     startedConnecting       <server: when bind&listen succeeds why does anybody
                                                                 not invoke something like startedListenig ?>
- stop factory                          doStop

per transport connection events:
- on transport creation                 <none exists?why?>      <after connect() or listen() returns result, at this point
                                                                 we may decide to prevent further transport instantiation,
                                                                 especially if we are server-side protocol factory>
- transport creation failed             clientConnectionFailed  <server: direct analogy - accept() may return an error,
                                                                 but that event not exists for server. why?>
- transport created succesfully         buildProtocol           <a request to build a protocol instance implies, that
                                                                 transport instance have been succesfully created. or not?>
- build protocol                        buildProtocol           
- after transport and protocol creation clientConnectionMade    <in t.s.pb.PBXXXXFactory, event sent by protocol instance,
                                                                 name not defined in any Interface, why not?>
- transport closed                      clientConnectionLost    <why not define this for server too to be consistent?>

They are not client/servers asymmetric as I see them, but have asymmetric names in twisted
and sometimes when server variants exists, they have no fixed names defined in Interface classes :(

What is the difference between doStart and startedConnecting (together with imaginary startedListening)?

And who is responsible for sending which events? That is not defined in documentation.

What do you think about these names:
doStart()
transportFactoryStarted()
onBeforeTransportCreate()
connectionFailed()
buildProtocol()
connectionMade()
connectionLost()
doStop()
Well, I understand, you will veto them arguing by lot of code using old names,
but I am interested to know will they break the abstraction of protocol factory?

Can please anyone explain the asymmetry of the interfaces of protocol factories
and tell how can it be useful for me.

Thanks for your time.

Alexey.

-- 
с уважением,
Алексей Шпагин
системный администратор
цеха передачи данных
технического центра телекоммуникаций
ОАО "ВолгаТелеком" 
филиал в Удмуртской республике.