Networking Research

This page is where the Foundation will publish research on networking for constrained devices: how embedded systems stay connected, what it costs them, and how the network stack behaves when the link is not the clean laboratory connection that most protocol testing assumes. Networking is one of the places where the gap between how a stack is specified and how it behaves in the field is widest, and that gap is worth studying.

Nothing is filed here yet. The networking layer exists in the platform — it is implemented in the eNI repository on GitHub — but no research write-up has been published about it. This page holds the space for that research and describes what it will cover.

On a server or a phone, the network stack is a solved problem that the operating system hands you. On a constrained device — a sensor with kilobytes of RAM, a battery that has to last years, a radio link that drops half its packets — the stack is a research problem. Every connection kept open costs power. Every retransmission costs energy. Every byte of stack state costs memory that could have gone to the application.

The questions that matter here are concrete: how does the stack behave when packets are lost; how much memory does it hold under real traffic rather than in a benchmark; what is the power cost of staying connected, and where can the protocol or the implementation be shaped to reduce it. These are not theoretical questions. They decide whether a deployed device meets its battery budget.

The Foundation's networking implementation is the eNI repository on GitHub, which is part of the public EmbeddedOS platform. Like all Foundation software, it is MIT licensed, and the source is there for anyone to read, audit and build on.

Research published in this category will be research about that implementation — measured, examined and written up — not research about networking in the abstract. The point of studying our own stack is that the findings can feed directly back into the code, and readers can verify every claim against the source.

Future write-ups will examine behaviour under loss: how the stack's reliability mechanisms respond to degraded links, and what the measured cost of that response is. They will examine the memory footprint of the stack as a function of connection count and traffic pattern, not just as a single best-case number. And they will include real-world link measurements — radio environments, lossy links, the conditions devices actually see — with the test setup described in full.

Write-ups will also state their limits plainly: what was tested, what was not, and where the results should not be extrapolated. A measurement taken on one radio and one traffic pattern is a data point, not a universal truth, and the write-ups will say so.

The same rule applies here as on the Linux research page: measurements come before publication. Networking claims are especially easy to assert and especially hard to verify — a throughput number without a described setup is an advertisement — so nothing will appear here until there are measured results with a described method behind them.

That means this page stays empty while the measurement work is being set up. The empty state is not a backlog; it is the Foundation refusing to publish assertions dressed as research.

Until research write-ups appear, the eNI repository on GitHub is the place to watch: it is where the implementation lives, and the commit history shows how it is evolving. Questions about the networking layer can go to the contact page, and if you have measurement data, test setups or field experience with constrained-device networking, the Foundation would like to hear from you — write to partners@embeddedos.org about research collaboration.

All findings, designs and filings from the Foundation's research programme are published openly rather than licensed, and that applies here too: when networking research exists, it will be free to read, free to check and free to build on.