4 ms·
There's no simple slam-dunk on either side of this issue, but I was a bit surprised that some of the more common arguments that I've heard in favor of kernel ne
by notacoward 6y ago
There's no simple slam-dunk on either side of this issue, but I was a bit surprised that some of the more common arguments that I've heard in favor of kernel networking didn't get mentioned.
The #1 reason I've heard is features. When you use the kernel stack you have a dizzying array of protocols, congestion-control algorithms, and other features available to you. You have all sorts filtering and rerouting and rate-control features, from old iptables to netfilter and eBPF. There's all sorts of familiar monitoring. User-space stacks never duplicate all of this, nor should they. They should support their own use cases, no more, but that means there will still be a lot of people who are better off with the kernel stack.
The #2 reason I've heard is that the kernel stack is known to work in a broad variety of environments. User-space stacks are often used in constrained environments where the device only has to communicate in certain ways with certain peers across a certain network topology. The kernel stack is known to work in a vast array of combinations simultaneously with less need for local debugging. There are also security aspects here. For example, a good TCP/IP stack will have features to mitigate DoS attacks both inbound and outbound, whereas some user-space stacks do things like "forget to implement" proper congestion control so they can DoS others. Whatever vulnerabilities do exist in the kernel stack tend to become known and fixed rather quickly. In your user-space stack? Good luck.
I'm not actually arguing that more people should use the kernel stack. There are plenty of good reasons to go the other route when appropriate. I'm just trying to present arguments I've seen and which should be considered when making that choice. The OP seems to look at things from a bit of a "single machine, single purpose" POV, which naturally skews the outcome toward user-space stacks, but in an era of virtualization and containers we need to consider multi-purpose machines as well.
- regularfry 6y agoWouldn't both of these be neutralised somewhat if you took a rump-kernel approach of some sort? Use a real kernel network stack, just run it in user-space with whatever parts you don't need ripped out?
- ohazi 6y agoThese are the same reasons you should opt for an SoC that can run Linux over a "wifi microcontroller" if your embedded project needs networking and has the cost and power budget to support it. The Linux community has spent the last 25 years finding and fixing bugs that you absolutely will encounter if you use the Microchip or Espressif or SiLabs networking stack.
- monocasa 6y agoEh, those almost always use lwip, which is probably the only stack that can rival the Linux and BSD stacks in man hours spent fixing bugs and adding support for different envs. I don't think any of those companies are writing their own stacks.
- Matthias247 6y agolwip is indeed decent. At least as decent as all the C based work is which lacks any decent unit-tests to make sure it keeps working (the linux kernel is not better). The problem with those embedded solutions is often not lwip but that the integration and requirements between lwip, the OS and it's task system (e.g. FreeRTOS), and the actual hardware is not properly understood. Which can e.g. lead to function calls being made from the wrong context - which could work in the beginning - might lead to weird errors later on. For this reason I would also recommend people who want to build connected devices to build on top of a more mature and streamlined stack - like the Linux TCP/IP stack plus associated drivers.
- dan-robertson 6y agoI find #2 quite compelling. I also find the monitoring differences are important. If you have a userspace stack then things like lsof or packet capturing will work differently. If your stack is polling rather than getting interrupts you likely won’t even be able to look at cpu usage or load averages (each polling loop will run at 100% cpu looking for new network activity)
- Melkman 6y agoI think an other reason to use the Linux stack is that it's performance is good enough for most every task. Writing your own stack will cost you a lot of time and is only advantageous if there is a big improvement in performance and that improvement is really needed. A bit like a software libraries and frameworks. If you write your application without frameworks you can probably speed up your application quite a bit. But it will cost you a lot of extra development time.