Handling multiple clients via Sockets
-
Hey there! Been a while… took a little break from bugging you all with questions ;-). Anyways I was working on a server/client project so I could just become familiar with socket programming before I took a little "programming" break. Now that I'm going to continue it I had a few questions about trying what I'm attempting to do. What I want is to create a Agent-Based monitoring application. So the idea would be to have the server sitting out on the WAN listening for connections from the agents. The agents will upload data and will perform more actions in the future. So what is the best way to handle multiple connections? The connections could range anywhere from 1 to 750 agents that checkin every 30 seconds. Some products that come in mind is Labtech, Kaseya, and Zenith. I was using async sockets and see tons of people out there just creating new threads on a new connection, but surely this will kill the server when you get many connections. Should I be using a thread pool (haven't dove into how to do this yet), creating new threads, async sockets, or what? Thanks!
-
Hey there! Been a while… took a little break from bugging you all with questions ;-). Anyways I was working on a server/client project so I could just become familiar with socket programming before I took a little "programming" break. Now that I'm going to continue it I had a few questions about trying what I'm attempting to do. What I want is to create a Agent-Based monitoring application. So the idea would be to have the server sitting out on the WAN listening for connections from the agents. The agents will upload data and will perform more actions in the future. So what is the best way to handle multiple connections? The connections could range anywhere from 1 to 750 agents that checkin every 30 seconds. Some products that come in mind is Labtech, Kaseya, and Zenith. I was using async sockets and see tons of people out there just creating new threads on a new connection, but surely this will kill the server when you get many connections. Should I be using a thread pool (haven't dove into how to do this yet), creating new threads, async sockets, or what? Thanks!
maybe... best way use thread pool, and each socket response object use async call back... or anybody suggest more better solution. sorry..
-
Hey there! Been a while… took a little break from bugging you all with questions ;-). Anyways I was working on a server/client project so I could just become familiar with socket programming before I took a little "programming" break. Now that I'm going to continue it I had a few questions about trying what I'm attempting to do. What I want is to create a Agent-Based monitoring application. So the idea would be to have the server sitting out on the WAN listening for connections from the agents. The agents will upload data and will perform more actions in the future. So what is the best way to handle multiple connections? The connections could range anywhere from 1 to 750 agents that checkin every 30 seconds. Some products that come in mind is Labtech, Kaseya, and Zenith. I was using async sockets and see tons of people out there just creating new threads on a new connection, but surely this will kill the server when you get many connections. Should I be using a thread pool (haven't dove into how to do this yet), creating new threads, async sockets, or what? Thanks!
-
There is also Socket.Select[^]
Interesting.. never seen that used.. I will have to check more into that.
-
Hey there! Been a while… took a little break from bugging you all with questions ;-). Anyways I was working on a server/client project so I could just become familiar with socket programming before I took a little "programming" break. Now that I'm going to continue it I had a few questions about trying what I'm attempting to do. What I want is to create a Agent-Based monitoring application. So the idea would be to have the server sitting out on the WAN listening for connections from the agents. The agents will upload data and will perform more actions in the future. So what is the best way to handle multiple connections? The connections could range anywhere from 1 to 750 agents that checkin every 30 seconds. Some products that come in mind is Labtech, Kaseya, and Zenith. I was using async sockets and see tons of people out there just creating new threads on a new connection, but surely this will kill the server when you get many connections. Should I be using a thread pool (haven't dove into how to do this yet), creating new threads, async sockets, or what? Thanks!
For a checkin every 30 seconds you might want to consider UDP or reconnecting each time. The recommended way to do TCP is using the asynchronous methods; as you correctly guess creating lots of threads can cause problems. A lot of people (including myself!) start out that way because it's easy, it's how you did it in Java and the documentation for the asynchronous sockets is not that great. What's likely to be the biggest problem in this design is that you will be using up to 750 sockets. That will be a bigger hit than the use of .Net objects with such a low load. A quick search turned up this excellent article on high performance use of the asynchronous socket methods.
-
Hey there! Been a while… took a little break from bugging you all with questions ;-). Anyways I was working on a server/client project so I could just become familiar with socket programming before I took a little "programming" break. Now that I'm going to continue it I had a few questions about trying what I'm attempting to do. What I want is to create a Agent-Based monitoring application. So the idea would be to have the server sitting out on the WAN listening for connections from the agents. The agents will upload data and will perform more actions in the future. So what is the best way to handle multiple connections? The connections could range anywhere from 1 to 750 agents that checkin every 30 seconds. Some products that come in mind is Labtech, Kaseya, and Zenith. I was using async sockets and see tons of people out there just creating new threads on a new connection, but surely this will kill the server when you get many connections. Should I be using a thread pool (haven't dove into how to do this yet), creating new threads, async sockets, or what? Thanks!
Only one comment - if you've got 750 clients, make sure they connect, do whatever they have to do and disconnect immediately afterwards (or force disconnect them). Holding lots of idle sockets open will kill scalability. This is the approach webservers use. And for lots of short lived connections, the threadpool is definitely your friend. When you accept a socket through a TcpListener or similar pass the socket to a method and throw it on the threadpool.
Regards, Rob Philpott.
-
For a checkin every 30 seconds you might want to consider UDP or reconnecting each time. The recommended way to do TCP is using the asynchronous methods; as you correctly guess creating lots of threads can cause problems. A lot of people (including myself!) start out that way because it's easy, it's how you did it in Java and the documentation for the asynchronous sockets is not that great. What's likely to be the biggest problem in this design is that you will be using up to 750 sockets. That will be a bigger hit than the use of .Net objects with such a low load. A quick search turned up this excellent article on high performance use of the asynchronous socket methods.
I haven't read that link you put up yet but I kind of skimmed through it. It appears that it is using libraries newer than .NET 2.0. I should of mentioned that I wanted to stick with nothing above .NET 2.0. Now for stuff like Labtech I really think they are using a web service (which I do not want to use). I can't really use UDP because the agent has to be able to retrieve data back from that server when it checks in. This is because the server will not really have access to any agent directly since they are on different networks. So the agent has to be the one to start the connection and accept data back.
-
Only one comment - if you've got 750 clients, make sure they connect, do whatever they have to do and disconnect immediately afterwards (or force disconnect them). Holding lots of idle sockets open will kill scalability. This is the approach webservers use. And for lots of short lived connections, the threadpool is definitely your friend. When you accept a socket through a TcpListener or similar pass the socket to a method and throw it on the threadpool.
Regards, Rob Philpott.
So only handle so many connections at one time… but do not reject any? It almost sounds like if I don't get the calculation right I could end up in a loop (meaning some agent actions not being performed in the correct amount of time before it tries to checkin again)
-
I haven't read that link you put up yet but I kind of skimmed through it. It appears that it is using libraries newer than .NET 2.0. I should of mentioned that I wanted to stick with nothing above .NET 2.0. Now for stuff like Labtech I really think they are using a web service (which I do not want to use). I can't really use UDP because the agent has to be able to retrieve data back from that server when it checks in. This is because the server will not really have access to any agent directly since they are on different networks. So the agent has to be the one to start the connection and accept data back.