Threads and TCP/IP
Author
I'm was reading a DotNet book about networking. More specifically TCPIP and creating servers.
They were creating a thread for each connection. My thoughts would be that once you get about 100 users on your system, it would start to bog down due to thread overhead. It's also kinda sloppy to see a process with 100 threads in task manager.
Is that the way to do it? Or were they doing something sloppy?
A low end server could probably get away with creating a new thread for every connection. Something higher up along would use a thread pool, i.e. a predefined set of threads which are called sequentially and released after they have run their course, to be called again when needed with a new connection. I'm not sure about anything higher to be honest with you...
Thats just intended as a very basic example of how it could be handled.
Thats just intended as a very basic example of how it could be handled.
Its because its easy! If you write your thread to handle one connection, it can block without hassle and serve whenever it likes - its pretty much like just writing a single client server then thinking "oh i can just put this in a thread and suddenly i can handle lots of clients". So when you have very few clients connected at once its a good idea simply because its easy. If your writing a webserver or something with more than just a few clients connected at once it will chug you very badly. However for smaller servers its quite simple and easy to impliment.
Author
So on bigger servers like webservers, what would you do then?
Have an array of the TCPIP sockets and "WaitForMultipleObjects" on the sockets, and when one gets a message, then you process? Wouldn't that also block any other messages that would be waiting while the first one was processing? But then again webservers are probably pretty snappy... Just "Get page" place 2k of page data in the stream and go, process next... Probably doesn't take much processing power.
Just curious, how much does a big webserver handle for clients at any given time? Say www.cnn.com, or something big like that? I'm sure they load-balance the server, but how many clients do you think 1 server takes care of?
Have an array of the TCPIP sockets and "WaitForMultipleObjects" on the sockets, and when one gets a message, then you process? Wouldn't that also block any other messages that would be waiting while the first one was processing? But then again webservers are probably pretty snappy... Just "Get page" place 2k of page data in the stream and go, process next... Probably doesn't take much processing power.
Just curious, how much does a big webserver handle for clients at any given time? Say www.cnn.com, or something big like that? I'm sure they load-balance the server, but how many clients do you think 1 server takes care of?
Like doodle_sketch you use a thread pool. You spin up one thread per cpu, associate all your sockets with an io completion port (this is Windows I'm talking about), and as each bunch of data comes in the first available thread will pick it up.
The key thing is that you don't want to waste a bunch of time context switching between threads, therefore it doesn't make sense to have more than one active thread per cpu.
The key thing is that you don't want to waste a bunch of time context switching between threads, therefore it doesn't make sense to have more than one active thread per cpu.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement