Discussion:
Server process communicating with multiple PC's
(too old to reply)
D-Fan
2008-07-31 19:20:21 UTC
Permalink
I am writing a server process that will communicate with multiple pc's
on an as needed basis. I might have 200 - 300 PC's connected at the
same time. If I see a certain flag set I want to be able to send the
user a message. Is it best to have a thread per user to handle this
message communication or is a thread pool better at handling this?

If I use a thread pool how can I manage it so that different threads
look at different client connections?
Craig Hammon
2008-08-01 05:10:58 UTC
Permalink
You could make hundreds of threads..
If the Hub or server is making contact with the Client,

Then why not make the clients listen for a contact..
So, the client has a listening port.. and becomes a server itself.

the Hub makes contact with the workstation, and in this case, acts as a
client, since its initiating contact
if you do it this way, you only need one thread on the listening server on
each workstation.
hope that makes sense..
Post by D-Fan
I am writing a server process that will communicate with multiple pc's
on an as needed basis. I might have 200 - 300 PC's connected at the
same time. If I see a certain flag set I want to be able to send the
user a message. Is it best to have a thread per user to handle this
message communication or is a thread pool better at handling this?
If I use a thread pool how can I manage it so that different threads
look at different client connections?
D-Fan
2008-08-01 17:27:24 UTC
Permalink
The clients will check their local ports via a timer and a thread
process. They will not request from the server unless they find a flag
in their receive port which tells them to go to the server. The goal is
to reduce unnecessary network traffic and database query processes.
Post by Craig Hammon
You could make hundreds of threads..
If the Hub or server is making contact with the Client,
Then why not make the clients listen for a contact..
So, the client has a listening port.. and becomes a server itself.
the Hub makes contact with the workstation, and in this case, acts as a
client, since its initiating contact
if you do it this way, you only need one thread on the listening server on
each workstation.
hope that makes sense..
Post by D-Fan
I am writing a server process that will communicate with multiple pc's
on an as needed basis. I might have 200 - 300 PC's connected at the
same time. If I see a certain flag set I want to be able to send the
user a message. Is it best to have a thread per user to handle this
message communication or is a thread pool better at handling this?
If I use a thread pool how can I manage it so that different threads
look at different client connections?
Craig Hammon
2008-08-03 15:11:29 UTC
Permalink
If you are using a thread, dont use a timer. Use a sleep..

But my point was, ether side of the conversation can act as the listening
side.. If deach client was a listening, you wouldnt need multi threads.
Post by D-Fan
The clients will check their local ports via a timer and a thread
process. They will not request from the server unless they find a flag
in their receive port which tells them to go to the server. The goal is
to reduce unnecessary network traffic and database query processes.
Post by Craig Hammon
You could make hundreds of threads..
If the Hub or server is making contact with the Client,
Then why not make the clients listen for a contact..
So, the client has a listening port.. and becomes a server itself.
the Hub makes contact with the workstation, and in this case, acts as a
client, since its initiating contact
if you do it this way, you only need one thread on the listening server on
each workstation.
hope that makes sense..
Post by D-Fan
I am writing a server process that will communicate with multiple pc's
on an as needed basis. I might have 200 - 300 PC's connected at the
same time. If I see a certain flag set I want to be able to send the
user a message. Is it best to have a thread per user to handle this
message communication or is a thread pool better at handling this?
If I use a thread pool how can I manage it so that different threads
look at different client connections?
D-Fan
2008-08-04 07:18:23 UTC
Permalink
Post by Craig Hammon
If you are using a thread, dont use a timer. Use a sleep..
But my point was, ether side of the conversation can act as the listening
side.. If deach client was a listening, you wouldnt need multi threads.
Post by D-Fan
The clients will check their local ports via a timer and a thread
process. They will not request from the server unless they find a flag
in their receive port which tells them to go to the server. The goal is
to reduce unnecessary network traffic and database query processes.
Post by Craig Hammon
You could make hundreds of threads..
If the Hub or server is making contact with the Client,
Then why not make the clients listen for a contact..
So, the client has a listening port.. and becomes a server itself.
the Hub makes contact with the workstation, and in this case, acts as a
client, since its initiating contact
if you do it this way, you only need one thread on the listening server
on
Post by D-Fan
Post by Craig Hammon
each workstation.
hope that makes sense..
Post by D-Fan
I am writing a server process that will communicate with multiple pc's
on an as needed basis. I might have 200 - 300 PC's connected at the
same time. If I see a certain flag set I want to be able to send the
user a message. Is it best to have a thread per user to handle this
message communication or is a thread pool better at handling this?
If I use a thread pool how can I manage it so that different threads
look at different client connections?
How do you make a thread sleep? I have seen suspend, but not sleep. Is
this a case where you would enter a repeat loop in the read with a
sleep call inside the loop?
Craig Hammon
2008-08-04 14:11:41 UTC
Permalink
Yes,
In a thread, you can


While ACondition do // Prob while connected etc.
Begin
LookForIncomingData;

Do your stuff...


Sleep(10000); // Sleep 10 seconds.
End;
Post by D-Fan
Post by Craig Hammon
If you are using a thread, dont use a timer. Use a sleep..
But my point was, ether side of the conversation can act as the listening
side.. If deach client was a listening, you wouldnt need multi threads.
Post by D-Fan
The clients will check their local ports via a timer and a thread
process. They will not request from the server unless they find a flag
in their receive port which tells them to go to the server. The goal is
to reduce unnecessary network traffic and database query processes.
Post by Craig Hammon
You could make hundreds of threads..
If the Hub or server is making contact with the Client,
Then why not make the clients listen for a contact..
So, the client has a listening port.. and becomes a server itself.
the Hub makes contact with the workstation, and in this case, acts as a
client, since its initiating contact
if you do it this way, you only need one thread on the listening server
on
Post by D-Fan
Post by Craig Hammon
each workstation.
hope that makes sense..
Post by D-Fan
I am writing a server process that will communicate with multiple pc's
on an as needed basis. I might have 200 - 300 PC's connected at the
same time. If I see a certain flag set I want to be able to send the
user a message. Is it best to have a thread per user to handle this
message communication or is a thread pool better at handling this?
If I use a thread pool how can I manage it so that different threads
look at different client connections?
How do you make a thread sleep? I have seen suspend, but not sleep. Is
this a case where you would enter a repeat loop in the read with a
sleep call inside the loop?
D-Fan
2008-08-05 05:29:04 UTC
Permalink
Post by Craig Hammon
Yes,
In a thread, you can
While ACondition do // Prob while connected etc.
Begin
LookForIncomingData;
Do your stuff...
Sleep(10000); // Sleep 10 seconds.
End;
Snip
Thanks for the tip

Craig Hammon
2008-08-04 14:13:03 UTC
Permalink
If you want some very simple Client/Server components, contact me. I use
these for commercial products and they are easy to use. Simple simple
simple.
Post by D-Fan
Post by Craig Hammon
If you are using a thread, dont use a timer. Use a sleep..
But my point was, ether side of the conversation can act as the listening
side.. If deach client was a listening, you wouldnt need multi threads.
Post by D-Fan
The clients will check their local ports via a timer and a thread
process. They will not request from the server unless they find a flag
in their receive port which tells them to go to the server. The goal is
to reduce unnecessary network traffic and database query processes.
Post by Craig Hammon
You could make hundreds of threads..
If the Hub or server is making contact with the Client,
Then why not make the clients listen for a contact..
So, the client has a listening port.. and becomes a server itself.
the Hub makes contact with the workstation, and in this case, acts as a
client, since its initiating contact
if you do it this way, you only need one thread on the listening server
on
Post by D-Fan
Post by Craig Hammon
each workstation.
hope that makes sense..
Post by D-Fan
I am writing a server process that will communicate with multiple pc's
on an as needed basis. I might have 200 - 300 PC's connected at the
same time. If I see a certain flag set I want to be able to send the
user a message. Is it best to have a thread per user to handle this
message communication or is a thread pool better at handling this?
If I use a thread pool how can I manage it so that different threads
look at different client connections?
How do you make a thread sleep? I have seen suspend, but not sleep. Is
this a case where you would enter a repeat loop in the read with a
sleep call inside the loop?
Michael Justin
2008-08-01 17:21:46 UTC
Permalink
Post by D-Fan
I am writing a server process that will communicate with multiple pc's
on an as needed basis. I might have 200 - 300 PC's connected at the
same time. If I see a certain flag set I want to be able to send the
user a message. Is it best to have a thread per user to handle this
message communication or is a thread pool better at handling this?
Maybe a message oriented middleware (available as open source, for
example Apache ActiveMQ or xmlBlaster) could be helpful for this task.
These solutions are cross-platform/cross-language (suited for hundreds
or thousands of clients), have a very high performance, low footprint,
and easy to install and use. They support any type of message, including
objects (for example JSON encoded) between the clients and servers.

Best Regards
--
Michael Justin
SCJP, SCJA
betasoft - Software for Delphi™ and for the Java™ platform
http://www.mikejustin.com - http://www.betabeans.de
D-Fan
2008-08-04 05:48:24 UTC
Permalink
Post by Michael Justin
Post by D-Fan
I am writing a server process that will communicate with multiple pc's
on an as needed basis. I might have 200 - 300 PC's connected at the
same time. If I see a certain flag set I want to be able to send the
user a message. Is it best to have a thread per user to handle this
message communication or is a thread pool better at handling this?
Maybe a message oriented middleware (available as open source, for
example Apache ActiveMQ or xmlBlaster) could be helpful for this task.
These solutions are cross-platform/cross-language (suited for hundreds
or thousands of clients), have a very high performance, low footprint,
and easy to install and use. They support any type of message, including
objects (for example JSON encoded) between the clients and servers.
Best Regards
Thanks for you help, and I will be glad to look at it. My experience
with lots of good open source products is that they tend to be very
good, but poorly document on how to use them. I have spend lots and
lots of hours trying to figure out how some of the products works. I
have spent enough time that there are times when I could have written it
myself. This is not true of some of the open source, but some of it
very much like this. Look at really implementing OpenSSL and it
encryption features as an example.
Loading...