[Twisted-Python] From asyncore to twisted
drew.smathers at gmail.com
Fri May 2 10:20:36 EDT 2008
On Thu, May 1, 2008 at 6:09 PM, Daniel Brandt <daniel.brandt at gmail.com> wrote:
> I'm looking for some advice on how to get started with an asyncore ->
> Twisted conversion. Being new to twisted I have some trouble getting
> started (re)designing my system. All ideas are welcome since I'm also
> doing this to learn.
> I am about to convert a message-passing daemon written with asyncore
> to Twisted, and I have two goals in mind. Code that is easier to
> maintain and expand, and higher reliability. The last part would
> probably be achievable while sticking with the present code, but since
> I keep hearing I really should use Twisted instead, I figured I'd try
> it out :-).
> The daemon listens for connections from different peers. Some peers
> just leave a message and disconnect, some peers connect as receivers
> and linger waiting for messages. A message will be given to the daemon
> by a messenger, and forwarded by the daemon to exactly one of the
> connected receivers. The daemon keeps a data structure (a dict with
> identifier: channel, actually) of receivers which it cycles through in
> a round-robin fashion.
One common strategy in twisted is to keep a list of your connected
clients (Protocol instances) as part of the factory. See:
So in the dataReceived method on you Protocol, you would do something like:
> There are more scenarios as well; (recievers may send status messages
> back to the daemon that the daemon logs, some messengers linger
> waiting for confirmation from a receiver and a few other) but they arees,
> mostly just variations of the above.
> I'm a bit confused about what parts should be in the Protocol and what
> should be separated away from it. Should I make a specialized Factory
> or make a Service (or several depending on what type of client
> connection it is)?
I think generally it is a good idea to have a specialized Factory as
this binds global state for you Protocol instances. The server howto
linked above describes this pattern quite well.
> I realize there is a lot in my description that's open for
> interpretation, but since I'm mostly after design ideas and good
> practices, I'm hoping that's OK..
The finger tutorial does a good job of explaining many aspects of
twisted, and this might give you some ideas of how to leverage its
parts for your application:
\\\\/ // //\/\\\\\\\
\\\/ \\// /\ \/\\\\
\\/ /\/ / /\/ /\ \\\
\/ / /\/ /\ /\\\ \\
/ /\\\ /\\\ \\\\\/\
More information about the Twisted-Python