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

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

Hey Laslo,

On 09/14/20 02:56PM, 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"

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.

Received on Sun Oct 04 2020 - 16:06:51 CEST

This archive was generated by hypermail 2.3.0 : Sun Oct 04 2020 - 16:48:33 CEST