I decided to try Fan for something a bit bigger and implement a mud server in it.. Haven't got too far yet :-) I have been trying to wrap my head around the threading model and how to fit socket communication there but haven't really succeeded yet.
I think I need a thread for every connection because some operations are blocking but I can't let them to stop the world. So I have a thread for every connection but I can't seem to make that one thread to both receive messages from mud world to pass to the client (this would make the thread to sit in the receive loop) and simultaneously wait input from the client(this would make the thread sit in readLine or similar) and send them to the mud world. Do I need two threads per every connection that sounds a bit excessive or am I just thinking in circles.. Someone please help :-)
Thanks in advance!
brianWed 29 Oct 2008
Fan doesn't have async IO right now, so you do need to design with the sync IO APIs. How you structure it is really dependent on your protocol. If your protocol is basic request/response, then you can probably get away with one thread. In fact this is how Fan's basic webserver works - take a look at the wisp code.
But I've also designed high performance protocols where I'll use 2 or 3 threads per connection. For example a protocol used extensively at my day job is designed to use three threads:
one thread to read messages off the socket as fast as possible and stick them onto a dispatch queue
a dispatch thread which takes messages off the queue and processes them, potentially sending back responses
a send thread which is responsible for sending messages on the send queue
That protocol is pretty sophisticated as it supports request/response, async messaging, and file based streaming all over one TCP connection. Although three threads per connection is pretty heavy weight and does effect scalability (you have to tune your max stack size to pack in more threads).
A good way to think about Fan is to think about worker threads and queues. You don't actually need to build your own queues because every thread has a built-in queue - just use the sendSync and sendAsync methods.
sampo Wed 29 Oct 2008
I decided to try Fan for something a bit bigger and implement a mud server in it.. Haven't got too far yet :-) I have been trying to wrap my head around the threading model and how to fit socket communication there but haven't really succeeded yet.
I think I need a thread for every connection because some operations are blocking but I can't let them to stop the world. So I have a thread for every connection but I can't seem to make that one thread to both receive messages from mud world to pass to the client (this would make the thread to sit in the receive loop) and simultaneously wait input from the client(this would make the thread sit in readLine or similar) and send them to the mud world. Do I need two threads per every connection that sounds a bit excessive or am I just thinking in circles.. Someone please help :-)
Thanks in advance!
brian Wed 29 Oct 2008
Fan doesn't have async IO right now, so you do need to design with the sync IO APIs. How you structure it is really dependent on your protocol. If your protocol is basic request/response, then you can probably get away with one thread. In fact this is how Fan's basic webserver works - take a look at the wisp code.
But I've also designed high performance protocols where I'll use 2 or 3 threads per connection. For example a protocol used extensively at my day job is designed to use three threads:
That protocol is pretty sophisticated as it supports request/response, async messaging, and file based streaming all over one TCP connection. Although three threads per connection is pretty heavy weight and does effect scalability (you have to tune your max stack size to pack in more threads).
A good way to think about Fan is to think about worker threads and queues. You don't actually need to build your own queues because every thread has a built-in queue - just use the sendSync and sendAsync methods.