SFML community forums

Help => Network => Topic started by: EiTkoCaT on September 13, 2011, 02:49:13 pm

Title: Best Way To Handle Thousands of UDP packets in a second
Post by: EiTkoCaT on September 13, 2011, 02:49:13 pm
Hey,


I need to handle from each client 30 packets per second. I have like 500 clients connected in the same time. I need to get a packet, process it and give an answer. What would be the best way to do that? Selector? SFML Threads? Boost Threads?

Thanks.
Title: Best Way To Handle Thousands of UDP packets in a second
Post by: Laurent on September 13, 2011, 03:11:15 pm
You don't need anything "complicated". UDP is not a connected protocol, so you can receive and answer to all of your 500*30 packets with a single socket.
Title: Best Way To Handle Thousands of UDP packets in a second
Post by: EiTkoCaT on September 13, 2011, 03:14:26 pm
I'm using boost thread for each client connected via TCP and I'm opening another thread which binds to UDP. The TCP works perfect but I have a big delay on the UDP messages answers. What am I doing wrong? Should I use UDP selector? The packets must be answered immediately, it's a real-time game.
Title: Best Way To Handle Thousands of UDP packets in a second
Post by: Laurent on September 13, 2011, 03:27:17 pm
Is it one TCP thread + one UDP thread per client? So this is a total of 1000 threads?? (which can definitely kill your CPU)

You shouldn't have more than one socket, and thus one thread, for UDP. One socket/thread per client is pure overhead.

Even one TCP thread per client is a lot to handle for your OS and CPU. Here you could try a selector instead, or non-blocking sockets + polling.

But anyway, you should profile your app. At least monitor your hardware to find the bottleneck: is the network traffic at its maximum? Is the CPU at 100%? ...
Title: Best Way To Handle Thousands of UDP packets in a second
Post by: EiTkoCaT on September 13, 2011, 03:41:57 pm
Yes, currently it is like that. The TCP thread is kind of most, but I think I will have one thread for the UDP which is a selector.

The problem is the CPU. I'm not using, not even close to maximuum network traffic. But I'm using 250% CPU. I have 400%.

So would that solve my problem - Using the UDP selector? Somethings to notice: The TCP messages are answered very fast, while the UDP can come in a delay of 10 seconds. Not milliseconds. Maybe I should do 2 programs running? One TCP and the second only UDP updates on-the-game? IT is possible.

Thanks a lot.
Title: Best Way To Handle Thousands of UDP packets in a second
Post by: Laurent on September 13, 2011, 04:08:46 pm
You don't need a selector for UDP because you need only one socket.
Title: Best Way To Handle Thousands of UDP packets in a second
Post by: EiTkoCaT on September 13, 2011, 04:10:28 pm
Ok, so I'll just create one thread that listens to the UDP.

But do you think that would solve the problem? What do you think about what I wrote on my last post?


Thanks.
Title: Best Way To Handle Thousands of UDP packets in a second
Post by: Laurent on September 13, 2011, 04:11:42 pm
I have no idea. If your CPU is the bottleneck, you should profile your application to know what consumes the most of it. It could be your game logic, and have nothing to do with networking itself for example.

But reducing the number of threads (2 instead of 1000) will already be a huge improvement.
Title: Best Way To Handle Thousands of UDP packets in a second
Post by: EiTkoCaT on September 16, 2011, 06:02:30 pm
Hey,

I have fixed that and it's still not working well. All the packets are coming but in a delay of 10 seconds. What should I do?