-
Notifications
You must be signed in to change notification settings - Fork 12
Design Overview
This page is intended to collect details together about the various choices we have to make and pieces we have to build.
- Event loop and threading model? Can we slide user threads under Rust?
Sandstorm currently makes the assumption that all RPC requests can be encapsulated inside a single UDP + IP packet. This assumption simplifies network processing considerably.
Netbricks, a packet processing engine written in Rust already has a set of DPDK bindings. Sandstorm is currently built over these DPDK bindings. On boot up, a server creates a dispatch layer over Netbricks that constantly polls a set of hardware queues for packets. If there are packets queued up at the NIC, the dispatcher picks them in a batch, performs a few sanity checks on the MAC, IP, and UDP fields of the packet, and hands each one off to the corresponding service - currently, Sandstorm supports only one service called "Master". The service then handles the RPC request according to the opcode in the request's header. This approach is very similar to that adopted by the RAMCloud key-value store.
Sandstorm is currently single threaded, with the same thread responsible for both, dispatch, and hash table lookups.
- Perhaps ordered and unordered variants?
- Table heap management? Scan support?
- Replication