Archived
This forum has been archived. Please start a new discussion on GitHub.
Is the "thread per connection" model the only choice in ICE?
in Help Center
In the network circumstances, a server often has to deal with vast number of clients simultaneously. D.Schmidt discussed this situation in his <<Pattern-Oriented Software Architecture, Patterns for Concurrent and
Networked Objects, Volume 2>>:
One way to implement a logging server is to use some type of multi-threading model. For example, the server could use a 'thread-per-connection' model that allocates a dedicated thread of control for each connection and processes logging records as they arrive from clients. Using multi-threading can incur the following liabilities, however:
§ Threading may be inefficient and non-scalable due to context switching,
synchronization, and data movement among CPUs.
§ Threading may require the use of complex concurrency control schemes throughout
server code.
§ Threading is not available on all operating systems, nor do all operating systems provide portable threading semantics.
§ A concurrent server may be better optimized by aligning its threading strategy to available resources, such as the number of CPUs, rather than to the number of clients is services concurrently.
These drawbacks can make multi-threading an inefficient and overly-complex solution for developing a logging server. To ensure adequate quality of service for all connected clients,however, a logging server must handle requests efficiently and fairly. In particular, it should
not service just one client and starve the others.
He then proposed serveral design patterns to give the alternative choices such as reactor,proactor ect. In Ice,
if can I applie these design patterns ,say, reactor, to demultiplx the imcoming netwrok connections? I mean, if is the "thread per connection" model the only choice in ICE? If so, How dose the ICE solve the problems decribled by D.Schmidt?
In our current work, we have to construct a server to cope with at least 500 clients. Except the problem of "the thread per connection" ,which still confueses me, I think ICE is a very good choice to us.
Hope getting some helps.
Thank you for your time,
OrNot
Networked Objects, Volume 2>>:
One way to implement a logging server is to use some type of multi-threading model. For example, the server could use a 'thread-per-connection' model that allocates a dedicated thread of control for each connection and processes logging records as they arrive from clients. Using multi-threading can incur the following liabilities, however:
§ Threading may be inefficient and non-scalable due to context switching,
synchronization, and data movement among CPUs.
§ Threading may require the use of complex concurrency control schemes throughout
server code.
§ Threading is not available on all operating systems, nor do all operating systems provide portable threading semantics.
§ A concurrent server may be better optimized by aligning its threading strategy to available resources, such as the number of CPUs, rather than to the number of clients is services concurrently.
These drawbacks can make multi-threading an inefficient and overly-complex solution for developing a logging server. To ensure adequate quality of service for all connected clients,however, a logging server must handle requests efficiently and fairly. In particular, it should
not service just one client and starve the others.
He then proposed serveral design patterns to give the alternative choices such as reactor,proactor ect. In Ice,
if can I applie these design patterns ,say, reactor, to demultiplx the imcoming netwrok connections? I mean, if is the "thread per connection" model the only choice in ICE? If so, How dose the ICE solve the problems decribled by D.Schmidt?
In our current work, we have to construct a server to cope with at least 500 clients. Except the problem of "the thread per connection" ,which still confueses me, I think ICE is a very good choice to us.
Hope getting some helps.
Thank you for your time,
OrNot
0
Comments
-
No, thread per connection is not the only choice. In fact, for the vast majority of applications using thread per connection this would be a very poor choice! Most applications should use the thread pool concurrency model, which is the default. You should read the manual which explains this in detail.
Regards, Matthew0
