[Twisted-Python] Factory question

[Drew Smathers]

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,
>  correct?

Yes.

> 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).
>

Ok.

> > 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
>  http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
>



-- 
\\\\\/\"/\\\\\\\\\\\
\\\\/ // //\/\\\\\\\
\\\/  \\// /\ \/\\\\
\\/ /\/ / /\/ /\ \\\
\/ / /\/ /\  /\\\ \\
/ /\\\  /\\\ \\\\\/\
\/\\\\\/\\\\\/\\\\\\
               d.p.s