Server Mux Rabbit Hole

Reading about go 1.22 release notes sent me on a semi-tangent about demultiplexers

Published on 2024/02/07

I was reading the Go release notes for v1.22 and other than the much anticipated rework on for loops I have been following the changes coming to ServerMux as detailed here. Whenever I work on small projects I try to avoid pulling in frameworks or libraries unless necessary. This means that I have been doing my own routing with all the pain that comes with it. To be fair it's not that bad if your API is pretty limited. If you've done this before you'll be familiar with something like this:

mux.HandleFunc(
  "/tag",
  func(w http.ResponseWriter, r *http.Request) {
    if r.Method == http.MethodDelete {
      // delete logic or call to tag deletion handler func
      return
    }

    if r.Method == http.MethodPost {
      // post logic or call to tag creation handler func
      return
    }

    w.WriteHeader(http.StatusMethodNotAllowed)
  },
)

If you need to manage multiple HTTP methods on the same route things escalate. With the changes introduced in 1.22.0 things look much brighter:

mux.HandleFunc(
  "DELETE /tag",
  func(w http.ResponseWriter, r *http.Request) {
    // tag deletion logic
  },
)

mux.HandleFunc(
  "POST /tag",
  func(w http.ResponseWriter, r *http.Request) {
    // tag creation logic
  },
)

* sorry for the funky formatting it just fits better in the page

I'm liking this a lot more and it extends to wildcards in patterns, like /tags/{id}. Generally routing has become more pleasant which means I'm ready to refactor a thing or two!

But believe it or not this is not why I'm writing this. I was thinking about the word "multiplexer" and wanted to understand its origin. The first half is intuitive where "multi" indicates "multiple". This makes sense since a multiplexer has to deal with multiple data streams and forward the selected input into a single processor (in our case the routing mechanism forwards to a different handler based on URL path). What got me was the "plex" part which apparently comes from Latin (unsurprisingly) and it refers to the weaving together or combining of multiple signals into one. Then it got me thinking about demultiplexers. While uncommon as a concept at the application level it is pretty common at the networking level. It's all about directing packets to the proper receiving application based on the metadata in the header, port numbers for TCP/UDP for example.

Here's where my understanding got it wrong or where my mental model was incorrect. Intuitively I compared this to the fan-out pattern in queue systems where a message is distributed to multiple destinations. So why not call it a demultiplexer? To an extent it can almost be considered one but demultiplexing is about forwarding a packet to the correct endpoint by choosing the right one given multiple choices. In the case of a fan-out pattern we actively distribute to several destinations. So while demultiplexing is about selective routing ,fan-out is about distribution.

Thoughts

I like following my curiosity and making sure my mental models are correct. It was interesting to learn about multiplexing and its history a bit which had the goal of maximizing the efficiency of communication channels. Multiplexing and demultiplexing were used to send multiple telegraph messages over a single wire simultaneously. So on one end you would do the multiplexing and combine them into one, on the other end you would do the demultiplexing and separate the transmission back into the original messages.

This made me think about a very interesting book called "The Master Switch" which I highly recommend. It goes over the history of communication in a very captivating way showing you how innovation comes along not by chance. It is also filled with fun facts, I should probably pick it up again!

← Go Back