[Twisted-Python] Factory question
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.
> write the protocol to support bidirectional comm and to create the
> 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
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 127.0.0.1:57821! <-- ok, Client1
daemon proto instance 2
Connection from 127.0.0.1:57821! <-- Client1 again????? why?
Connection from 127.0.0.1:57823! <-- ok, Client2
daemon proto instance 3
Connection from 127.0.0.1:57821! <-- ok, Client1 again????? why?
Connection from 127.0.0.1:57823! <-- ok, Client2 again????? why?
Connection from 127.0.0.1:57824! <-- 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