hey, I had a quick design question - this should be a fairly common
thing (I would think it would have been done a million times before):
I need a server to fork off requests to a thread that handles requirements. I guess the model would be:
CLIENT asks SERVER to handle request on standard port.
SERVER tells CLIENT port to listen on, and forks off THREAD that listens on a given port.
CLIENT talks to THREAD that then handles transaction, sending response
back to CLIENT
SERVER is then free to listen for other requests.
But - how do you handle broken pipes? How do you handle two clients connecting at the same time? what about runaway threads? How about the ports in question being blocked and the resources being overwhelmed by multiple inward boung connections?
There's GOT to be a prebuilt solution for this sort of thing, where you simply plug in the request classes and away you go...
I'd like to know of any prebuilt solutions, if you could give me a hand, you can reach me at horos@apxtech.com
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The TCPService class is designed as an intermediary model. Where TCPSession assumes each client connection will have a seperate thread, this may be heavy handed if you have many active client connections, or if they are of generally very short duration (like a web server). TCPStream assumes one thread handles all connections and this is not good either. In this sense, TCPService represents a compromise where 1 or more threads (a thread pool in effect) could be used to service connections, and for SMP platforms and for handling a very high number of connections, this has some chance to work much better. Balancing the pool is manual although one could create automatic classes that balance a thread pool based on the TCPService model. In that sense, I think it's the most "scalable" model.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
hey, I had a quick design question - this should be a fairly common
thing (I would think it would have been done a million times before):
I need a server to fork off requests to a thread that handles requirements. I guess the model would be:
CLIENT asks SERVER to handle request on standard port.
SERVER tells CLIENT port to listen on, and forks off THREAD that listens on a given port.
CLIENT talks to THREAD that then handles transaction, sending response
back to CLIENT
SERVER is then free to listen for other requests.
But - how do you handle broken pipes? How do you handle two clients connecting at the same time? what about runaway threads? How about the ports in question being blocked and the resources being overwhelmed by multiple inward boung connections?
There's GOT to be a prebuilt solution for this sort of thing, where you simply plug in the request classes and away you go...
I'd like to know of any prebuilt solutions, if you could give me a hand, you can reach me at horos@apxtech.com
never mind... I found the TCPService class... I guess I had a question though... what problems am i going to have with scalability?
Ed
The TCPService class is designed as an intermediary model. Where TCPSession assumes each client connection will have a seperate thread, this may be heavy handed if you have many active client connections, or if they are of generally very short duration (like a web server). TCPStream assumes one thread handles all connections and this is not good either. In this sense, TCPService represents a compromise where 1 or more threads (a thread pool in effect) could be used to service connections, and for SMP platforms and for handling a very high number of connections, this has some chance to work much better. Balancing the pool is manual although one could create automatic classes that balance a thread pool based on the TCPService model. In that sense, I think it's the most "scalable" model.