C# Socket Server - Max Capacity & General Questions

Question

I have an existing server application that keeps track of various computers on a network. Sometimes the network can have up to 6000 computers that need to be tracked. Tracking involves just knowing that a computer is powered on. Occasionally the server will send back messages to the client that need to be processed and handled.

I've tried WCF, but it doesn't seem to handle a large load very gracefully (high CPU usage is pretty common when approaching the 1200-2000 range of clients); plus, with WCF I have to make it sort of a "pull" mechanism instead of a "push" to get messages to the client (ie, client asks the server for messages). I'm thinking about switching over to low-level TCP socket communication, but I'm not sure what to expect, which is what this question is about.

So:

1 - How many clients can I expect to be able to connect to and stay connected to my server? 2 - Assuming this connection is primary being used to simply let the server know if a client is still online, and to send a very occasional message from the server, am I likely to see much resource use (in terms of CPU/RAM/tcp ports/etc) on the server?

Thanks

Answer 1

Do you really need to keep that many connections open?

It's not because you need to keep "track" of workstations that there needs to be a persistent connection. You could have the clients connect and poll, as you suggested, on an interval. Which architecturally has some resemblance to HTTP. This way a webserver might even fit your server needs: all the clients that are polling can be considered up, and your server might have something to say, or it might not. It doesn't really matter, just as long as you keep the connection open as short as possible. Using this approach combined with a relaxed poll-timout will most likely easily cover the aforemention 6000 workstations "tracked" by one server.

Another option might be to consider a messaging infrastructure. The server sends out commands to a command queue, and clients that pick up the commands respond over a response queue.

I guess UDP can be considered a possible way of implementing the latter. But you'll have to do more work...

Answer 2

1 - How many clients can I expect to be able to connect to and stay connected to my server?

5000 should not be any problem at all.

2 - Assuming this connection is primary being used to simply let the server know if a client is still online, and to send a very occasional message from the server, am I likely to see much resource use (in terms of CPU/RAM/tcp ports/etc) on the server?

Define "much". TCP connections that are open takes up resources. But the biggest resource will be the byte[] buffer that you are using in your BeginReceive. But let's assume that it's 32768 bytes large. That's a total of approx 163Mb. Memory is cheap, isn't it?

As for CPU usage, no. Idle connections doesn't use any CPU.

Answer 3

Take a look at this bytes.com question regarding the theoretical maximum number of connections allowed in what sounds like a similar situation.

The response that seems to be most relevant is:

The magic setting you're looking for is "MaxUserPort". You can google this,
then make the appropriate registry change.

The value is typically set at 5000, and if you want lots and lots of client
connections then you need to bump the value up.

That said you would likely benefit from using UDP over TCP in a local LAN environment if it mixes well with your design. I haven't personally performed any benchmarks on this in C# but have successfully supported over 10,000 UDP clients in C++ with little issue (and a HUGE box).