First, I am sorry because it's not a question related to twisted.
But since twisted is a networking programming framework, you might be
Some of my colleagues have a view that a net work server should be split to
small parts with different functions,
either with processes communicating with socket, or with threads talking on
Their points are these:
1. Each part could it's own state-machine, thus we could split big
state-machines to decoupled small ones.
2. It makes a pipe line that could handle some requests at the same time
without introducing lock problem of threading.
Just like how CPU use pipe line to improve performance.
3. It resembles a micro-kernel system which is supposed to have better
As far as I know, some networking device manufactures use this model to
implement their routers or switches.
but I have never heard any examples besides that.
As twisted book says, most networking application use one of these 3 modes:
1. handle each connection in a separate operating system process, in which
case the operating system will take care
of letting other processes run while one is waiting;
2. handle each connection in a separate thread1 in which the threading
framework takes care of letting other threads
run while one is waiting; or
3. use non-blocking system calls to handle all connections in one thread.
(Like twisted or lib-event or just select)
After considering for a while, I thought there are some faults in the
multiple parts model:
1. Writing code to handle message is much more tedious than just doing
2. It's not very easy to make a pipe line works fine.
OK, hope I made myself clear. Since most of you who are reading this mail
are experienced networking programmers, I think you might give some insight