I'm using Twisted in a custom server which I've written for ACB Radio Interactive (http://interactive.acbradio.org/), or ACBRI for short. ACBRI is a non-commercial "Internet radio station" run by blind and visually-impaired people (myself included), playing music in a variety of styles. We use the Shoutcast MP3-streaming system (www.shoutcast.com), in which the broadcaster sends the encoded audio to the server (over a TCP connection), and the server sends that audio to all currently connected clients. We wanted to provide a high-quality audio stream for users with broadband Internet connections, while not preventing modem users from listening. One way to solve this problem is for the broadcaster to simultaneously send two separate streams to the server (or potentially two different servers), one encoded at a high bit rate and one at a low bit rate. But not everyone can do that, due to lack of adequate CPU time or bandwidth or the limited functionality of the Windows applications most of the broadcasters use. So my idea was that the broadcaster should send only one stream to the server, which should re-encode that stream (using an external MP3 encoder like LAME) into a low-bandwidth stream for modem users and make that one available on a different port. Our server also needed to be able to relay one or both of the streams to another Shoutcast server in case we didn't have enough bandwidth on our own machine to serve many listeners. I knew of no server that did these two things, so I decided to write my own. I had written a Shoutcast-compatible server in Python a few months earlier, but it used threads to handle multiple connections (using the classes in the SocketServer module). After reading Sam Rushing's description of Medusa and his tutorial on the asyncore and asynchat modules, I knew that I should drop multithreading in favor of a single-threaded asynchronous approach. So I figured I'd rewrite my server sometime but never got around to it, and one thing that hindered me was the lack of built-in support for delayed callbacks in asyncore (for timeouts which are necessary in some cases). It seemed that it would be too difficult to implement the new requirements in my original multi-threaded server (which was probably poorly designed in other ways as well), so I decided to throw it out and start over. At that point I took a look at Twisted and chose to use it. I think the two main features that made me decide to use Twisted instead of asyncore+asynchat were built-in support for delayed callbacks and the Process class (since I needed to start the MP3 encoder and communicate with it through pipes). Initializing a server and handling a new incoming connection are also easier under the twisted.internet framework, and I thought the telnet server was cool. This leads me to what I don't like about Twisted. After taking a closer look at Medusa, I found that Medusa's "monitor" is better if you don't use a GUI (and therefore can't use Twisted Manhole). I guess I ought to write a command-line Manhole client using the twisted.internet.stdio module. I'd also strongly recommend moving the higher-level components into separate packages. For example. I have no use for Twisted Reality or Words and don't currently use Twisted Spread, though Twisted Web may come in handy in the future (I currently only use the low-level twisted.protocols.http module). I started working on this server in August. ACBRI has now been using it for a little over two months. It is not released to the public, at least not yet; if it's released, it will be under the GPL. Sorry if this is too long; feel free to condense and paraphrase what I've said as much as you like. I hope you found it interesting. -- Matt Campbell E-mail and MSN Messenger: mattcampbell@pobox.com Web site: http://www.pobox.com/~mattcampbell/

Ok, so here's a quick summary of what I use Twisted for... I'm a developer for a company that processes stock data and publishes it via the web and our own proprietary protocol. While the bulk of our systems are written in C++, I occasionally manage to do some things in Python which the C++ developers think would be too tedious (but are actually pretty simple in Python). My C++-coding colleagues were concerned that a moderately important server I proposed to write in Python wouldn't be fast enough, and that I'd end out using something dodgy like one thread per socket which would kill performance. Our systems all run on Win 2000, and many of the C++ servers make use of relatively obscure features like IO completion ports to improve performance. So I used Twisted. It is just beautifully simple to write an asynchronous, single-threaded server with Twisted. I've got a Python implementation of our internal protocol that inherits from twisted.protocols.protocol.ServerProtocol, and by writing a class which inherits from my class and overrides a single method, "queryRecevied", you can write a server for our systems. At least one of the C++ developers is now talking about writing his next server in Python. As for the speed, I'm getting nearly 200 requests/sec for this particular application, which is without doing any sort of optimisation, and involves processing by other servers due to the design of our company's systems, and involves processing XML in my server. This compares nicely with our C++ servers :) I haven't yet looked at half the things that Twisted can do (in particular, I'm interested in seeing if twisted.enterprise supports MS SQL Server 7 via the ADODB COM objects, or is easily adapted to it).... but I'm looking forward to finding out. Twisted makes writing a scalable server disgustingly easy. I regret that I cannot mention specific products -- this is all closed-source stuff used internally. I'm using Twisted 0.12.3, but am looking forward to the next version which will presumably fix the bug where startFactory gets called twice <wink> The only real problems I've had with Twisted so far are: * Having to admit that I need to delete those 50 lines of code because Twisted makes me realise I can do it in 15 * Trying to figure out how to make Twisted do everything for me, when it turns out that I really just needed something incredibly simple. (I got so used to thinking Twisted's framework could do it all, I started to muck about with Deferreds, until I realised that I just wanted keep a list of functions to run as soon as another function finished, which is something you can do with vanilla Python perfectly well :) * Having a semi-legitimate reason to IRC from work, so I can ask the friendly people on #python questions about Twisted :) Oh yes, and I'd like to mention that I like how if Protocol.dataReceived for some reason throws an exception, Twisted keeps on working (after logging the exception), rather than killing the whole server. I realise it's a simple thing, but I'm glad it's been done. I'm also interested in run-time configuration/status info -- am I right in believing there is a simple way to create a web interface for inspecting a Twisted application? (Our systems typically export a COM interface which is then manipulated by VB apps, but exporting COM interfaces from NT services in Python is a bit messy). Hmm. That wasn't as quick as I intended, but I hope you find it to be of some use. Keep on Twistin'... -Andrew.