[Twisted-Python] Factory question
drew.smathers at gmail.com
Thu Feb 28 10:39:52 EST 2008
On Thu, Feb 28, 2008 at 9:42 AM, Gabriel Rossetti
<mailing_lists at evotex.ch> wrote:
> 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,
> 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?
The protocol instance does not get reused.
> 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().
This is might be a bad idea - depending on the locality of your
servers and clients. Why not just use the established connection? If
the *client* is listening on a port then it isn't just a client - it's
a server, or a peer in a clustered system.
> 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.
The book it is not up to date.
> BTW, any idea why I'm getting this type of behavior (one server, 3
> distinct connections from clients) :
Without seeing your code, no.
> 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.
> Twisted-Python mailing list
> Twisted-Python at twistedmatrix.com
\\\\/ // //\/\\\\\\\
\\\/ \\// /\ \/\\\\
\\/ /\/ / /\/ /\ \\\
\/ / /\/ /\ /\\\ \\
/ /\\\ /\\\ \\\\\/\
More information about the Twisted-Python