The thing that really gets me as a small-time OSS maintainer is that none of us asked for this. The social and technical millieu where most of us started our projects is not the one we find ourselves in today, and the forces behind this are wildly asymmetric.
Security findings are one place where we as maintainers simply do not have the choice to not play ball, whether we like it or not. It seems likely that the only way that we meet the moment is to adopt these tools ourselves -- once again -- whether we like it or not. Reconciling this with the ground truth that 'OSS doesn't owe anyone a goddamn thing' is proving to be really hard for me.
As an HTTP server author, this doesn't surprise me.
We've ceded HTTP specification development to the big guys, and in so doing have made it more or less impossible to implement without resources on their scale. Have you looked at RFC 9000 et al? They're monstrously big, far larger than most independent shops could ever hope to economically pull off. The only way to comprehensively implement something of that scale is to have Google level resources to throw entire teams of engineers and years of focus at it.
I've long said that any protocol worthy of being foundational should be reasonably implementable as a fourth-year term project. It doesn't have to be production ready or ergonomic or even generally useful, but if a group of fourth year CS students can't pull an end-to-end implementation together in a semester, the protocol is just too complex. It's not perfect, but it's as good of a yardstick as I've found.
HTTP/1 passes this test easily; you can make a working version of it in about ninety seconds right in your terminal. HTTP/2 looks intimidating at first glance, but it's so much better specified than HTTP/1 that it's almost easier to get to a reasonable implementation. HTTP/3 on the other hand is...... well, weeks (if not months) of work just to get a QUIC foundation working reasonably well enough that you could hope to start iterating on connections from a 'real' peer, and THEN you have to start on RFC 9114. Not to mention that the way it's structured you end up doing most of that work in the dark, hoping that you line everything up just so so that your first Hello World actually works. It's a way of working that is completely at odds with the hacker ethos that the best foundational protocols have in spades, and ends up looking and acting like what it is: a tool by the big guys, for the big guys. The rest of the internet need not apply.
TBH, from an implementors perspective this is a super obvious thing to cover off. It had long been on my radar and was something that I'd always figured other implementations had defended against as well.
The fact that a critical piece of the evidence was cell phone photos sent between workers coordinating door re-assembly doesn't exactly instill a whole lot of confidence in their permit-to-work process. I didn't like it when it was medical teams doing shift handover via a Google Doc, and I don't like it when it's a matter of flight safety either. Or, as Homer might eruditely say: "guess I forgot to put the bolts back in" [1]
2. I wish the build would have used something like an MCP23017 for IO instead of claiming so many RPi GPIOs. There's only a few (2-3 IIRC) GPIOs unused by the front panel, and the matrix LED/switch scan setup burns a ton of CPU
BMath (CS) 2002 here. This description is spot on the way I think about development, and is a bit of a superpower to be able to do well. I'm not totally sure it's a UW-ism though. I can certainly recall a couple of very formative Tompa courses where he impressed the importance of taking a data-first view of design, and I think we had a stronger bias towards data structures than most other schools whose grads I've worked with. But overall I think that sentiment grew weaker in my upper years, when a more conventional algorithms approach took over.
I will say though, that I've also noticed the contrast before with MIT grads, who tend to have a very strong LISP bent to their styles. It's true that each school has their own unique flavour, and much like accents it may just be that you don't notice your own.
Bandit author here. Correct! The byline of Bandit is ‘a web server for Plug applications’ and being able to focus on that narrowed set of requirements is a large part of where the perf boost comes from (less code, easier to reason about, fewer processes, etc).
The PR you linked to adds support for generating new phx apps with the relevant change already incorporated; it’s just a generator change. We’re waiting a bit to incorporate this change to ‘soft launch’ Bandit support.
I couldn't stop thinking about this, so I went back and dug up an ancient (20yo+) copy of my OS implementation for the trains course (mat(t)OS). Sure enough, we did indeed dispatch the upper half of interrupts to processes, albeit via a dedicated blocking syscall rather than send/receive/reply semantics. Bottom half handlers (which were implemented behind task gates and had persistent stacks) just did the standard bottom half stuff: disabling interrupts & managing state so we could properly unroll after the interrupt had been handled.
Fascinating talk. The overall approach here strikes me as being extremely influenced by QNX's design. Send/Receive/Reply as a messaging primitive is too often overlooked, and provides incredibly powerful that (as Cliffe mentions) renders an enormous amount of scheduling complexity as moot.
Anyone who's done the UWaterloo trains course will recognize these patterns immediately, and (IIRC) interrupt dispatching is was done in a similar manner there as well.
Finally, the supervision patterns here strike me as being very similar to those within the BEAM, and remind me of the infamous quote from Robert Virding (http://erlang.org/pipermail/erlang-questions/2008-January/03...). Obviously a necessary reimplementation here, but humorous nonetheless.
Fundamentally, Bandit just does a lot less work than Cowboy does. Particularly with HTTP/1 requests, Bandit uses a single process per connection in contrast with Cowboy's 2 per connection. This allows Bandit's handler code to be very 'linear' and free of coordination complexity; for the most part, an HTTP/1 connection will go from initial connection to Plug call and back again without having to leave the process at all.
More broadly, there's just less functionality in Bandit (by design; it's a very focused library that doesn't need to do a bunch of the stuff that Cowboy does). All that stuff ends up adding up when you're doing it 100k a second.
This correlates with Bandit's relative numbers being better in HTTP/1 (up to 5x faster than Cowboy) than they are in HTTP/2 (a paltry 2.3x faster than Cowboy).
In terms of the 32 concurrent connections peak, my hunch here is that it's due to the server the test is running on being a 32 core VM (see https://github.com/mtrudel/network_benchmark for details of the benchmarking process). Truthfully I'm no expert with benchmarking & this may not hold a lot of truth; at the end of the day the test is pretty apples to apples so I think it has comparative merit, but the absolute numbers are a bit murkier to me.
Bandit is an HTTP server, not a client. It performs the same job in the stack as Cowboy does currently (just up to 5x faster as this post's title alludes to).
The Bandit project shares a small amount of code with the Mint project (Andrea & Eric were kind enough to factor out their HTTP/2 header compression library for use in Bandit), but this is mostly due to HTTP being a largely symmetric protocol (ie: there is a lot of functionality used equally by both clients and servers).
A number of the first trans-atlantic cables landed in the tiny village of Heart's Content, Newfoundland. I drove through there on a road trip about a decade ago & stopped at the excellent museum in the old cable station, and was excited to make my way across the highway to the beach to see this exact thing. It turns out that the old cables are just.... left to rust on the beach. It's really amazing that these cables, originally a technological wonder & a bridge between entire continents, are just left to the elements once their useful life is over.
My goodness, you're right (well, your example isn't, but the feature I'm talking about has been present since at least 1.8 (the earliest install I have handy):
The use of prior matches in guards is super useful for parsing TLV style payloads where you first match on a size/length field and then match on the value itself as that number of octets. Does anyone have any insight into how / when similar support will make its way into Elixir?
As someone who writes Elixir full-time in a product with deeply complex date / time needs (spanning multiple timezones, sources of time, multiple meanings of 'month', etc), I can say with some conviction that the the simplicity of Elixir's DateTime module is most definitely a feature. The lack of something as transparent in Rails was / is a huge part of what makes our team so productive since porting the product to Elixir; NaiveDateTime alone has saved us from more bugs than I care to think about. Between Elixir core and Timex, they've definitely solved the harder corners of time as well as any other library or platform I've seen.
I did a lot of network work early in my career (high school job at a small town ISP in the early 90's), and have read deeply about / waxed nostalgia for the Arpanet era ever since.
Networking now is as different from my ISP days as they were to the days of IMPs. It's remarkable.
Security findings are one place where we as maintainers simply do not have the choice to not play ball, whether we like it or not. It seems likely that the only way that we meet the moment is to adopt these tools ourselves -- once again -- whether we like it or not. Reconciling this with the ground truth that 'OSS doesn't owe anyone a goddamn thing' is proving to be really hard for me.