71–80 of 345 posts
> A separate process is started for each incoming connection, and that process is wholly focused on serving that one connection. It makes you wonder just how "heavy" operating system processes actually are. We may not need to worry about the complexity of trying to multiple run async requests in a single process/thread in all cases.
So what was the point of the async/callback web programming revolution if processes were good enough?
Earlier quoted context omitted.
Binary protocols aren't (or at least don't have to be) any more difficult and frequently are even easier to implement. Text protocols have difficult problems like escaping or detecting the end of particular field that are frequent source of mistakes. The issue is that many (especially scripting) languages treat binary data as second class. The only real issue is that inspecting the binary message visually is little b…
And capitalisation issues, and encodings… give me a binary protocol to parse any time. They’re normally comparatively well-defined, whereas text protocols are seldom properly defined and so have undefined behaviour left, right and centre, which inevitably leads to security bugs—or even if they are well-defined, they’re probably done in a way that makes your language’s string type unsuitable, and makes parsing more co…
> A separate process is started for each incoming connection, and that process is wholly focused on serving that one connection. It makes you wonder just how "heavy" operating system processes actually are. We may not need to worry about the complexity of trying to multiple run async requests in a single process/thread in all cases.
So what was the point of the async/callback web programming revolution if processes were good enough?
Granted, 10k concurrent requests is a problem for the 1% of websites, so processes were (and still are) good enough for the long tail of personal or small-scale websites.
Interesting but why? There’s a bazillion web servers out there, surely one of them can do the job? What have I missed?
> [Althttpd ...] has run the https://sqlite.org/ website since 2004 I don't know what the landscape was like in 2004 really, but probably at least an order of magnitude less than today's bazillion (whatever that would be!).
> A separate process is started for each incoming connection, and that process is wholly focused on serving that one connection. It makes you wonder just how "heavy" operating system processes actually are. We may not need to worry about the complexity of trying to multiple run async requests in a single process/thread in all cases.
If you only have around 100 concurrent confections, a separate thread per connection is entirely feasible. A whole new process is probably fine on Linux, but e.g. Windows takes pretty long to spawn a process
/* ** Test procedure for ParseRfc822Date */ void TestParseRfc822Date(void){ time_t t1, t2; for(t1=0; t1 There's only two billion integers, guess we can test them all. Well, substantially fewer than two billion with that skip. I wonder if that completes in a few seconds.
$ time ./althttpd-time-parse
Test completed in 10518961 us
real 0m10,521s
user 0m10,486s
sys 0m0,004s
This is on a Dell Latitude featuring a Core i5-7300U at 2.6 GHz, running Ubuntu 20.10.
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…
Once you have to support HTTP/1.1 it's not really a text-based protocol, because support for chunked encoding is mandatory for clients. (Yes the chunk headers are technically text, but it's interspersed with arbitrary binary data. It's not something you can easily read in a text editor.)
flex -8iCrfa Yahoo! serves chunked pages
printf 'GET / HTTP/1.1\r\nHost: us.yahoo.com\r\nConnection: close\r\n\r\n'|openssl s_client -connect us.yahoo.com:443 -ign_eof|./yy045