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>
localtime
used in str_timestamp_ex
can't do that, it's not threadsafelocaltime
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...