[Twisted-Python] integrating twisted into an existing application

Anthony Baxter anthony at interlink.com.au
Mon Feb 17 21:34:23 EST 2003


I have a large complex application that I'd like to start migrating
to twisted, and I'd appreciate feedback on how to implement this.

It's a large (around 17KLOC) voicemail server that works with a cisco
AS5x00 to provide unified messaging. It talks RADIUS, RTSP and RTP to
the cisco, IMAP and SMTP to the message stores, and has a telnet 
interface for administration and debugging. The current implementation
has a separate thread for each of the RTSP, RADIUS and telnet listeners,
and spawns a thread for each incoming request. 

Internally it has a cache of IMAP connections - when a RADIUS request
or an RTSP request comes in, it grabs the cached IMAP connection for
the user and does the request.

A typical request looks like:

cisco sends a number of RADIUS requests to the server - login, selectFolder,
nextMessage, and gets back RADIUS responses with various attribute-value
pairs indicating things like 'number of unread messages' or 'message-type'
or the like. It then sends in an RTSP request to start the message playback -
the server pulls down the data from the message store, decodes it if 
necessary, sends it to a text-to-speech server if necessary, then spawns 
a small C program to handle the actual RTP playback to the cisco.

There's a bunch of thorny issues that have to be handled - obviously 
you have a number of operations that can block when talking to the IMAP
server, there's the shared imap connection cache, it's all rather ugly.

Initially I was thinking I'd replace the telnet listener with a 
twisted reactor running in it's own thread - this can then do the
telnet server (and maybe ssh server). Moving the RADIUS or RTSP 
listeners to twisted means I'd need to find a way to do the IMAP
and SMTP (for message sending) in an async manner - I'm not sure
on the best way to do this. My initial thought would be to have a
pool of IMAP handler threads; when a RADIUS request comes in that
needs IMAP, it grabs an IMAP thread that's free (or creates a new
one) and gets it to do the operation (and signal back when it's 
done). Is this sort of thing a typical way to handle a stateful
protocol like IMAP? 


--
Anthony Baxter     <anthony at interlink.com.au>
It's never too late to have a happy childhood.





More information about the Twisted-Python mailing list