D
danavni
i need to build a service that will accept incoming TCP/IP connections.
the service should act like a "HUB" where on one side clients connect
to it and stay connected for as long as they like and on the other side
the service reads messages for these clients from MSMQ and sends them
to already connected clients. the clients can also send information
back to the "HUB" which will be parsed and sent to MSMQ.
when the clients connect to this service, they send their unique
identity to the server over the TCP/IP stream (the client ip is NOT
fixed so i can't use that for authentication).
i thought of 2 designs for this:
design 1:
1. have a class that listens for incoming connections (using the
TcpListener class).
2. when an incoming connection arrives, it accepts it and spawns a new
thread with the the incoming connection. the thread will receive the
incoming identity and then store itself (the thread class instance
along with the client's identity in a hashtable). then the thread
(class) will wait for more data from the client or will send data to
the client if the thread on item #3 calls a send data method.
3. have a class that periodically reads the MSMQ for messages to
clients. get the target client unique id, find the appropriate class in
the hash table and call the send data method for the specific class
(which in theory should still hold the connection open).
design 2:
1. have a class that listens for incoming connections (using the
TcpListener class).
2. when an incoming connection arrives, it accepts it and spawns a new
thread that will just read the unique id and add to the hashtable the
connection and the unique id as the key. this thread is then destroyed.
3. have another thread that will scan the hashtable all the time and
look for incoming data, read it and parse it.
4. have a thread than reads MSMQ for messages to the clients, pulls the
correct connection from the hashtable and send the message to the
client.
both designs should work but i would like to hear ideas and/or comments
about the designs.
what is the maximal number of threads i can spawn? max number of TCP/IP
clients the service can support?
i need a design that will be able to support as many clients as
possible but on the same time not be too demanding on server resources.
thanks
the service should act like a "HUB" where on one side clients connect
to it and stay connected for as long as they like and on the other side
the service reads messages for these clients from MSMQ and sends them
to already connected clients. the clients can also send information
back to the "HUB" which will be parsed and sent to MSMQ.
when the clients connect to this service, they send their unique
identity to the server over the TCP/IP stream (the client ip is NOT
fixed so i can't use that for authentication).
i thought of 2 designs for this:
design 1:
1. have a class that listens for incoming connections (using the
TcpListener class).
2. when an incoming connection arrives, it accepts it and spawns a new
thread with the the incoming connection. the thread will receive the
incoming identity and then store itself (the thread class instance
along with the client's identity in a hashtable). then the thread
(class) will wait for more data from the client or will send data to
the client if the thread on item #3 calls a send data method.
3. have a class that periodically reads the MSMQ for messages to
clients. get the target client unique id, find the appropriate class in
the hash table and call the send data method for the specific class
(which in theory should still hold the connection open).
design 2:
1. have a class that listens for incoming connections (using the
TcpListener class).
2. when an incoming connection arrives, it accepts it and spawns a new
thread that will just read the unique id and add to the hashtable the
connection and the unique id as the key. this thread is then destroyed.
3. have another thread that will scan the hashtable all the time and
look for incoming data, read it and parse it.
4. have a thread than reads MSMQ for messages to the clients, pulls the
correct connection from the hashtable and send the message to the
client.
both designs should work but i would like to hear ideas and/or comments
about the designs.
what is the maximal number of threads i can spawn? max number of TCP/IP
clients the service can support?
i need a design that will be able to support as many clients as
possible but on the same time not be too demanding on server resources.
thanks