[Twisted-Python] Factory question

Gabriel Rossetti mailing_lists at evotex.ch
Thu Feb 28 09:42:00 EST 2008

Drew Smathers wrote:
> On Wed, Feb 27, 2008 at 3:32 AM, Gabriel Rossetti
> <mailing_lists at evotex.ch> wrote:
>> Hello everyone,
>>  I have a small question, I have a service which needs to sometimes send
>>  data (without having received any prior to sending) and sometimes
>>  receive data, which is better :
>>  1) create a factory that inherits from ServerFactory and ClientFactory,
>>  thus it can listen and send data
>>  2) create a factory that inherits from ServerFactory only and uses a
>>  single-use client (ClientCreator, as shown in the writing clients howto)
>>  when it needs to send data
> I'm not sure of there's a single right way to do it, but I wouldn't
> bother inheriting from both ClientFactory and ServerFactory.  I think
> you're on the write track with 2, though.
I had taken route 1 up until now (I'm thinking about switching...)

Maybe there's something I haven't quite gotten, when ClientA initially 
connects to the server, the factory creates an instance of the protocol, 
correct? Now ClientA sends some data to the server, which processes it 
and sends something back. After that, the TCP session ends, and the 
client disconnects, and the protocols instance dies. Is this correct or 
does it live on and get reused somehow? I ask this because since 
initially the clients send data to the server (registration), the server 
will there after send data to the clients. This makes the client have to 
connect to the server initially though a port using reactor.connectTCP() 
and listen to a port (that the server now knows since the client 
registered itself) using reactor.listenTCP(). I think I have to use 
reactor.connectTCP() instead of  ClientCreator since the connection has 
to happen at the beginning and a transport needs to exist before I can 
send anything. Well...now that I think about it, I could have the 
factory register the client...... that would make me not have to inherit 
from the Client factory.... (I've now switched to solution 2, see last 
part of this email).
> In most use cases you shouldn't have to create custom factories.  
I have to since I need a non-reconnecting client xmlstream, and the 
factory used with xmlstreams is a reconnecting client.
> Just
> write the protocol to support bidirectional comm and to create the
> server:
> f = Factory()
> f.protocol = YourBidirectionalProtocol
> Regarding the client, how you implement it depends on whether or not
> the server is establishing the connection vs. reusing the existing
> connection.  
What exactly do you mean by reusing an existing connection?
> If you're establishing the connection (like in a cluster
> app with known peers), just use ClientCreator.  If you're reusing the
> existing connection, then you might not have to anything, unless you
> have some state to set up which could be done by overriding
> connectionMade on your Protocol.
> Finally, take everything I've stated above with a grain of salt.
Thanks, I find it fairly hard to get used to Twisted, I wanted to buy 
the book, but it was written in 2005 and I'm not sure if it's still 
valid with today's version.

BTW, any idea why I'm getting this type of behavior (one server, 3 
distinct connections from clients) :

Daemon listening for connections...

daemon proto instance 1
Connection from! <-- ok, Client1
daemon proto instance 2
Connection from! <-- Client1 again????? why?
Connection from! <-- ok, Client2
daemon proto instance 3
Connection from! <-- ok, Client1 again????? why?
Connection from! <-- ok, Client2 again????? why?
Connection from! <-- ok, Client3

Oh, and by the time I finished writing this email, I've switched to 
solution 2, but I still get the  behavior above.

More information about the Twisted-Python mailing list