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