You didn't actually address the concerns I laid out. And I acknowledged that a reverse proxy, appropriately configured, could mitigate the issue.
Re:You Should Feed the Bots
by cryptonector on Monday October 27, 2025 @03:47AM
(#45718340)
The way you deal with this is that you write the server to be async I/O based with NPROC threads, not a thread-per-client design, and then you can use CPS for the business logic, but in this case it's so trivial... You can probably get by with just a handful of bytes of memory pressure per client in the app + whatever the per-client TCB is for the TCP connection for a total of less than 200 bytes per client.
1. Start <thread_count> connections to a server
2. Hold connections open
3. Do nothing else
Server
1. Incoming connection. assign a thread.
2. Wait for request <--- Attack causes us to get stuck here
3. Serve request
4. Close connection and thread / return to threadpool
Solution: Use a reverse proxy to handle the incoming connections. Typical reverse proxies such as nginx use event-based polling not a per-connection thread so they are immune to this issue.