3 ms·

I love articles like this where it goes deeper into a fundamental idea that I've only interacted with on a "do what I need done" level.

• theamk 5y ago
  Fundamental? I see it the other way -- this is an illustration of how neat, fundamental concept ("When you bind to a port, it puts a pointer to your socket in that table.") is actually full of random hacks and ad-hoc changes. The linux kernel is full of random logic like this, and this article could be continued (there are at least network namespaces and sys.net options to consider). Don't get me wrong -- all of this functionality is useful in some context, and it is there for a reason. We cannot radically simplify the kernel without making it less useful. But it is still somewhat sad there is so much essential complexity even in simple things like "listen" call.
  • oblio 5y ago
    We can't really blame Linux for this, this is a networking protocols problem. It's their stack of hacks.
    • ratorx 5y ago
      Well only sort of. As far as I understand, nothing about TCP means that ports can be reused, or that 0.0.0.0 has special meaning, or that processes can’t listen on the same port, or IPv4 to IPv6 delivery etc. These are all operating system design choices, some of which stem from the sockets API. I’m pretty sure you could design a spec-compliant alternative which didn’t do any of these things, if you really wanted to.
    • wyager 5y ago
      TCP and UDP don't really dictate any of this behavior. Most of these hacks are the result of design choices in Linux and the socket API - abstractions on top of TCP/UDP that aren't the only option. In my experience, the network layer is often way better-designed, more reliable, more interoperable, and less hacky than most OS abstractions built on top of it.