[rwmj]

Cool! I also wrote my own C web server (sources linked below) which ran a commercial website for a while. It's amazing how small and light you can make an HTTP/1.1 webserver. The commercial site ran on a machine with 128MB of RAM and 1 CPU (sic) and routinely served a large proportion of schools in the UK with a closed source interactive, web-based chat system. However that was 20 years ago when the internet was a slightly less hostile place.

He mentions bots make great fuzzers, but I think he should also do a bit of actual fuzzing.

http://git.annexia.org/?p=rws.git;a=tree Requires: http://git.annexia.org/?p=c2lib.git;a=tree http://git.annexia.org/?p=pthrlib.git;a=tree

[nicoburns]

Rust is a good choice for webserver that will run in this footprint without having to worry so much about the hostile internet. My website https://blessed.rs runs on a VM with 256mb of RAM because that was the smallest I can find, but it typically uses ~60mb.

[kragen]

this looks much more practical than my own small and lightweight http/1.0 webserver, but i'm guessing that rws is not nearly as small and lightweight: http://canonical.org/~kragen/sw/dev3/server.s http://canonical.org/~kragen/sw/dev3/httpdito-readme

the really surprising thing about that was that when your memory map only has five 4k pages in it, linux gets really fast at forking

[rwmj]

It operated in the real world (of 20 years ago), and supported in-process dlopened modules which is how the web-chat was implemented, so it was somewhat non-trivial.

[kragen]

also, i'm assuming, comet, and thus long-lived connections that were in communication with each other, whereas httpdito spawns off a separate child process for each request and thus can fob off all the memory allocation and i/o multiplexing work onto the kernel

comet was a pretty compelling reason to write your own web server 20 years ago

[rwmj]

Not sure what comet is in this context?

The chat code [I really should upload the code as the company has been dead for at least 10-15 years] worked by browsers holding an infinitely loading frame, so each client held open a connection for several hours. IIRC there was some Javascript that reloaded the connection after a few hours.

To handle 1000s of HTTP connections we had to implement our own fairly lightweight threads. It also had a cool inversion of control where you could write straight through code and it was turned into event-driven callbacks automatically. The webserver couldn't make use of multiple cores, which was lucky because the server had only 1 CPU!

Also used a pool allocator, which is very well suited to server applications.

[kragen]

https://en.wikipedia.org/wiki/Comet_(programming) is browsers holding an infinitely loading frame, so each client held open a connection for several hours. usually we included <script> tags in that infinitely loading frame so the events could do whatever instead of just adding more text somewhere off the screen below the current scroll position. an alternative way to do comet is to close the connection when there's an event and have the client reload the frame

nowadays people use websockets for comet

yeah, protothreads type stuff and pool allocators are great fits for that kind of work

[cozis]

httpdito looks incredible

[kragen]

glad you like it!

[cozis]

Hey, the code looks really good! Thanks for sharing. I'll probably go through it a bit later :)

P.S. Love the indentation