Re: [hackers] [quark] Make the serving process interruptible || Laslo Hunhold

From: Jeremy <jer_AT_jer.cx>
Date: Sun, 4 Oct 2020 07:06:51 -0700

Hey Laslo,

On 09/14/20 02:56PM, git_AT_suckless.org 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
Received on Sun Oct 04 2020 - 16:06:51 CEST