Network stack

[Alan Mimms]

I want to say I am excited to see someone having the time to do this. I, and others, have been thinking of this sort of thing for a while now, and it just seems right. Thank you for getting it started!

What about networking? You point out on your README.md that you're planning a network stack, but you don't say if it's planned as C++ code or as JS code. I would strongly recommend the latter to give the capability of hooking into the stack easily at every stage, to write a stack that is easily understood and expanded, and to allow easy experimentation with new protocols to enhance/replace things like TCP.

A primary source of pain for today's OSes is shown clearly in the C10M problem - that is, achieving 10M simultaneous connections while accepting lots of packets per second on all of them. Today's OSes don't scale well on multicore CPUs for networking because the data structures for the stack - especially for TCP - are shared across all cores with locks that have lots of contention. What is needed is disaggregation at the bottom of the stack to a completely separate set of hash buckets and separately locked data structures per hash bucket. Some partition of the hash buckets would be assigned to each core for processing, and, ideally, a connection's application code would run on the same core as its connection is handled. Since each core handles a subset of the connections in the system, the handler could be built as run-til-complete, and the subset is partitioned, there is no possibility of lock contention, and the TCP stack can be completely lockless.

[Serge]

Thank you! I'm really excited about this project too.

Networking is one of the top priority components for the system. Web server application could make Runtime.JS actually useful.

I think network stack should be implemented in JavaScript. It naturally fits this way into platform. And it should be easier to implement and debug.

I like the idea to share the stack between multiple CPUs. It should be possible to split it into shared and CPU-local parts. Of course, we still need shared driver at the bottom that communicates with network adapter and dispatches packets to CPU-local handlers.

[Alan Mimms]

Yes. The bottom most layer would use simple (VERY important that it be inexpensive to compute) hash to disaggregate the flows to CPU cores and the associated data structures (effectively a separate stack per core or thread). That removes most of the need for locks if the code uses shared memory, or at least it eliminates most of the reasons for moving packets from one core to another by copying if the entire flow moves from base driver all the way up to the application that consumes the TCP flow data or whatever.