Hey Laslo,
On 09/14/20 02:56PM, [email protected] wrote:
> Make the serving process interruptible
>
> Given the static nature of quark, I wanted to try something out that
> is not really possible with a "dynamic" server: Making the serving
> process interruptible in constant memory (except dir-listings of
> course). This can easily be extended to a polling architecture later
> on, but it most importantly warrants a non-blocking I/O scheme and
> makes the server more or less immune to sloth attacks (i.e. clients
> sending requests very slowly), and provides a more flexible approach to
> connections. Any thread can pick up a connection and continue work on
> it, without requiring a separate process for each (which might hit the
> forking limit at some point). If we hit a point where all connections
> are busy (due to many sloth attacks), one can apply arbitrary complex
> logic to "cancel" connections that show malicious behaviour (e.g. taking
> a long time to send the request header, etc.).
>
Thanks to this patch, I've realized that there were two design desicions
made, which make quark easy to hack on, and easy to maintain:
1. Each resp_* function wrote 100% of the HTTP response
2. Each request is handled in a new process
1: Not only does this make it easier to read, but it also allows
an end user-developer to to:
- add their own non-standard header
- offload the the response generation to a different program,
a program that may set the "Content-Type" or "Set-Cookie"
headers
2: Forking for each request allows the end user-developer to manage
connections as he/she sees fit, while building on their existing knowledge
of process management.
Here's how I might prevent sloth attacks(this should kill children of
quark that are >10 seconds old):
ps --ppid $QUARK_PID -oetimes,pid | awk 'NR!=1 && $2 > 10 { print $2 }' |
> xargs kill
The command is not the important part, but that by using a well-known
process management interface, I can manage connections the way I like.
I believe that if one didn't want to use fork(3), while also keeping
the simplicity of quark, that person should rewrite quark in Golang.
I look forward to your feedback.
Jeremy
