Development of a scalable server

[Jonas Hei]

I need to develop a server application which would listen for UDP messages
(on a certain port, say 8464) and process each message (which entails
storing that data in the database) and then respond to it (via a UDP
message - sent to the client which sent the original message).

The server application needs to be highly scalable - it is expected to
handle upto 5000 clients simultaneously.

I believe a fork() and exec() like solution would need to be developed.
On windows, at least 3-4 years back, an application using IO Completion
ports would have been ideal.

I can choose .NET based development using C#. Or I can go for C++/ATL
based development also.
Can anyone point me to the best available options now?

 

[Les]

On a server that has to do 5000 at once, I'd look at
C++/ATL solution (just because it is more proven so less
risk).

 

[Nicholas Paldino [.NET/C# MVP]]

Jonas,

I would look at the UdpClient class. It might give you what you need.
I would just make sure that if you use that class, that you handle packet
processing on other threads.

Or, if you want, you can use the Socket class directly, and get notified
when you receive packets (through asynchronous callbacks).

I believe the Socket class does use I/O completion ports, so it should
meet your needs for scalability.

Hope this helps.

 

[Robert Jordan]

Jonas,

I would look at the UdpClient class. It might give you what you need.
I would just make sure that if you use that class, that you handle packet
processing on other threads.

on 5000 threads? ;-) since UdpClient is synchronous, I wouldn't
recommend it.

Or, if you want, you can use the Socket class directly, and get notified
when you receive packets (through asynchronous callbacks).

I believe the Socket class does use I/O completion ports, so it should
meet your needs for scalability.

bye
Rob

 

[Nicholas Paldino [.NET/C# MVP]]

Robert,

Which is why you use the Socket class directly. Just because you have
5000 clients simultaneously performing actions, doesn't mean that there are
5000 distinct packets from clients that need to be processed. I would
actually recommend the thread pool for something like this, assuming that
the packets themselves are small.