Althttpd: Simple webserver in a single C file • Hacker News Board

Re: Althttpd: Simple webserver in a single C file

#131

Post by cube00 » Tue, Jun 08, 2021, 1:23 PM UTC

TeMPOraL wrote: post #72

sydthrowaway wrote: post #61

Earlier quoted context omitted.

So what was the point of the async/callback web programming revolution if processes were good enough?

The point was that you didn't have the ability to spawn new threads at all . async lets you pretend you have threads, at the cost of everything being run through a hidden event loop.

I thought it was to get the best of both worlds in that you could max out a core with async to avoid context switching or waiting for blocked I/O but you still open up additional threads on more cores if you were becoming CPU bound.

Re: Althttpd: Simple webserver in a single C file

#132

Post by michaelmior » Tue, Jun 08, 2021, 1:24 PM UTC

einpoklum wrote: post #83

touisteur wrote: post #73

Earlier quoted context omitted.

Just use recordflux for binary parser proved absent of runtime errors... ;-)

Can you expand on that a little?

RecordFlux[0] is a DSL written in Ada for specifying messages in a binary protocol. Code for parsing these messages is then generated automatically with a number of useful properties automatically proven including that no runtime errors will occur.

[0] https://github.com/Componolit/RecordFlux

Re: Althttpd: Simple webserver in a single C file

#133

Post by michaelmior » Tue, Jun 08, 2021, 1:26 PM UTC

throw0101a wrote: post #128

zaarn wrote: post #113

Earlier quoted context omitted.

The reason HTTP is ASCII based isn't because it's easier to debug. It's because back then the other end was as likely to be a human as a piece of software. Because HTTP in it's early days barely had headers or even formatting, so people typed "GET /" at the server directly or used the same method to send mail directly. Nobody does that anymore and debugging is easily solved by converting your binary protocol to a tex…

I question the ascertain that humans were doing "GET /" or "HELO my.fq.dn" on any regular basis. There were mail clients from the very beginning for example: * https://en.wikipedia.org/wiki/History_of_email Perusing document-based information was also done via clients, first with Gopher and then with the WWW: either GUIs like Mosaic, or on the CLI via (e.g.) Lynx.

I definitely did back in the day :) But I'm only one single human.

Re: Althttpd: Simple webserver in a single C file

#134

Post by dnautics » Tue, Jun 08, 2021, 1:29 PM UTC

secondcoming wrote: post #57

ktpsns wrote: post #2

Here is the actual single C-code file: https://sqlite.org/althttpd/file?name=althttpd.c Something I absolutely love about text based protocols such as HTTP/1 is how easy you can implement it in any virtually programming language. Sure, the implementation is not top-of-the-notch, but it just damned works, it is portable, it is understandable by humans. That's something what's got lost with HTTP/2 and HTTP/3, respectiv…

Being text based is a huge flaw with HTTP in my opinion (and also elsewhere, like Redis). It leads to parsing bugs and overly verbose communications. Humans are good at reading text, CPUs prefer binary.

Being binary based leads to errors and loss of momentum when you are debugging something that's deployed to prod. It's all about tradeoffs.

Re: Althttpd: Simple webserver in a single C file

#135

Post by 0xbadcafebee » Tue, Jun 08, 2021, 1:29 PM UTC

> As of 2018, the althttpd instance for sqlite.org answers about 500,000 HTTP requests per day (about 5 or 6 per second) delivering about 50GB of content per day (about 4.6 megabits/second) on a $40/month Linode. The load average on this machine normally stays around 0.1 or 0.2

Interesting. If the load avg is consistently low, it could mean they're over-paying for CPU. If this was a non-dedicated AWS instance you might want low load so you don't chew up CPU credits, but you'd also want to use an instance type that creates some load so you're utilizing what you're paying for. Linode VPCs don't use cpu credits so the calculation is a bit simpler. I'm also curious how much of that bandwidth couldn't be offset by a CDN or mirrors.

If you were using a serverless platform, you'd ideally want to use something like static site hosting feature where you're mostly just paying for storage and egress. Or a serverless application platform to auto-scale traffic as needed. The main problem with doing this, of course, is the cost of egress: cloud providers with fancy serverless platforms often have redonkulous egress costs, so using a plain old VM on a VPC provider can be cheaper if you have more bandwidth demands than compute.

(I am aware none of this is a concern if you'd rather just spend $40 and forget about it. I am a nerd.)

Re: Althttpd: Simple webserver in a single C file

#136

Post by foo_barrio » Tue, Jun 08, 2021, 1:30 PM UTC

dvfjsdhgfv wrote: post #99

foobar33333 wrote: post #14

I'd be putting this in 1000 layers of sandboxing since its a C program with network access.

Maybe I'm getting old but these days I'm having a hard time telling if comments like these are serious or sarcastic.

It's definitely not you. There is a general term for this called "Poe's Law" that says something like: "a sufficiently thorough parody is indistinguishable from the original". That GP might be an example of this.

Re: Althttpd: Simple webserver in a single C file

#137

Post by john-tells-all » Tue, Jun 08, 2021, 1:31 PM UTC

niutech wrote: post #120

There is also redbean ( https://justine.lol/redbean/ ) - a single-file web server with embedded Lua interpreter as an Actually Portable Executable by Justine Tunney, the creator of Cosmopolitan.

The idea you can have an executable that is incredibly small, and runs on macOS/Linux/Windows, and is very fast, and has features, is mind-blowing.

Justine Tunney is a treasure!

Re: Althttpd: Simple webserver in a single C file

#138

Post by dmux » Tue, Jun 08, 2021, 1:32 PM UTC

spyke112 wrote: post #74

Sure it lives a single file, but considering the length, wouldn't it actually be better to split it into multiple files? I'm not that familiar with C, it seems to be a "thing" in C to just have giant files.

I've been thinking about this a lot recently. For most of my career I've been a Java programmer and for the majority of projects, each class is put in its own file. The amount of jumping (between files / following method calls) can get really tedious when you're trying to grok a code base. I've been working on Typescript projects recently where the standard has been to have slightly larger files -- possibly containing a class definition, but more often it's an entire module -- and it's actually been kind of nice to just read the entire thing top to bottom in one go. I've looked for studies on "locality" of source code, but haven't really found anything.

Re: Althttpd: Simple webserver in a single C file

#139

Post by jiofih » Tue, Jun 08, 2021, 1:34 PM UTC

throwaway525142 wrote: post #110

emn13 wrote: post #103

Earlier quoted context omitted.

I never understood the point of squashing if you just want the short version, only read the merge commits; if you want the full details to figure out some bug or whatever, then yes, I want those fix typo commits most definitely, because as often as not, those are at fault. Squashing buys you next to nothing, and costs you the ability to dive into the history in greater detail. I suppose if your project is truly huge,…

Squashing for example allows me to have a history where each commit builds. This has been very useful for bisecting for me. I wouldn't call it "next to nothing". The "greater detail" part can cost me a lot of time.

Having commits that do not build represents the history more accurately. It could very well be a “fix” to some build error that silently introduces an issue, that context is lost when you squash.

Re: Althttpd: Simple webserver in a single C file

#140

Post by throwaway525142 » Tue, Jun 08, 2021, 1:37 PM UTC

jiofih wrote: post #139

throwaway525142 wrote: post #110

Earlier quoted context omitted.

Squashing for example allows me to have a history where each commit builds. This has been very useful for bisecting for me. I wouldn't call it "next to nothing". The "greater detail" part can cost me a lot of time.

Having commits that do not build represents the history more accurately. It could very well be a “fix” to some build error that silently introduces an issue, that context is lost when you squash.

You're not saying anything new as far as I can tell. Your grandparent already said what you said. I only disputed the "this costs next to nothing" part, which you don't seem to comment on.