


nload to look at the amount of traffic but you seem to have those numbers already. Then I can recommend capturing one attack with tcpdump -w attack.pcap let that running for a short time during the attack then ctrl+c it. This is something you can then analyse after the fact. Then as fokko pointed out check your cpu usage. If your game server it self has cpu spikes and there is lags in game but your ssh is still smooth, then iptables will help. Or maybe even changing your game server code. You can try attaching a profiler and identify where the most cpu time is spent during an attack. There might be some way to change the code to make it more efficient. tcpdump -w attack.pcap? The few IPs they sent me traced back to another game host you might be familiar with NFO, however NFO believe the IPs were probably spoofed so no real luck there.
Lately we can barely play the game on the few publicly visible servers we have, as they get attacked immediately, for a small game like ours that essentially kills the game.
I'm looking to setup a server specifically designed to analyse the attack, and then hopefully we can see if we can actually mitigate it by buying more powerful machines and so on. Although I'm unsure right now how to go about doing all this, but I'm making progress I guess as some helpful people point me in the right direction.



tcpdump -w attack.pcap? The few IPs they sent me traced back to another game host you might be familiar with NFO, however NFO believe the IPs were probably spoofed so no real luck there.
Lately we can barely play the game on the few publicly visible servers we have, as they get attacked immediately, for a small game like ours that essentially kills the game.
I'm looking to setup a server specifically designed to analyse the attack, and then hopefully we can see if we can actually mitigate it by buying more powerful machines and so on. Although I'm unsure right now how to go about doing all this, but I'm making progress I guess as some helpful people point me in the right direction. 








tcpdump -w attack.pcap? The few IPs they sent me traced back to another game host you might be familiar with NFO, however NFO believe the IPs were probably spoofed so no real luck there.
Lately we can barely play the game on the few publicly visible servers we have, as they get attacked immediately, for a small game like ours that essentially kills the game.
I'm looking to setup a server specifically designed to analyse the attack, and then hopefully we can see if we can actually mitigate it by buying more powerful machines and so on. Although I'm unsure right now how to go about doing all this, but I'm making progress I guess as some helpful people point me in the right direction. tcpdump -w attack.pcap udp and dst port <yourport>












































(edited)































localtime used in str_timestamp_ex can't do that, it's not threadsafe















localtime in the code which is not thread-safe, localtime_r has been available in POSIX for a long time, localtime_s is available in msvcrt and localtime_r is available in mingw. Or we could bump up to C++20 and use std::chrono::zoned_time.
In more general ThreadSanitizer seems to find some actual real issues, at least I haven't encountered any false positives. It is expensive resourcewise though, so should we maybe enable it on CI if the resource cost isn't prohi...

























.%pid%.tmp files and rename them to the real filename when the recording is stopped. This ensures that .demo files are valid, assuming no io_write errors occur. If the client crashes or otherwise fails to stop the demo recording, then the invalid demos will stay .tmp files.
To simplify the usage, the handling of temporary files is added directly to the demo recorder. A parameter bool RemoveFile is added to the IDemoRecorder::Stop function to control wh...


