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

From: Laslo Hunhold <dev_AT_frign.de>
Date: Mon, 5 Oct 2020 09:01:18 +0200

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

Dear Jeremy,

thanks for your feedback!

> 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

Yes, even though it has its limits of course.

> 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.

This is just a remnant and will be changed later. I actually have quite
a lot of commits "lined up", which I haven't pushed, as I want to
handle sloth attacks better.

> 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.

Stay tuned for the upcoming changes, which implement worker threads
using epoll. In the case of a sloth attack, I want to implement it in a
way that each thread can look at its list of active connections and
select an offender to "drop" (e.g. first determine the IP-address from
which most requests originate or look at the total connection age or
the time since last activity). I like the idea of using external tools
to drop connections, but the forking-model, imho, just doesn't scale
well enough and I wanted a challenge. :)

Thanks again for your elaborate feedback, I really appreciate it! Stay
tuned for the upcoming changes.

With best regards

Laslo
Received on Mon Oct 05 2020 - 09:01:18 CEST