[gridspy]

Thread exhaustion attack

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.

[cryptonector]

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.

[kelnos]

You didn't actually address the concerns I laid out. And I acknowledged that a reverse proxy, appropriately configured, could mitigate the issue.