Child pages
  • RAMCloud 0.1
Skip to end of metadata
Go to start of metadata

Estimated time frame for implemention: 4-6 weeks

Goals for RAMCloud 0.1:

1. Setup development and testing environments.
2. Decide on a consistent coding style.
3. Implement skeletons for each major module of the system.
4. Combine code written by different people.
5. Write unit tests.
6. Setup an environment which facilitates performance measurements. Make baseline performance measurements (for lowest possible latency, and for a naive and unoptimized system based on TCP or UDP).
7. Decide on a marshalling/de-marshalling method.
8. Be able to startup a server process on a machine.
9. Setup git.
10. Flesh out the source code directory structure for the entire system.
11. Decide on a kernel version?
12. Decide on a open source license for the code.

Implementation and Environment related decisions made:

1. Use C/C++ as the implementation language.
2. Use git (on the fiz server) as the version control system.
3. The zeroth system should be implemented as a loadable kernel module. The aim is not to recompile the kernel for now.


The zeroth system should support the following RPCs:

  1. ping - send a packet from the client to the server and back again.
  2. read100(id, buf) - read 100 bytes from the server.
  3. write100(id, data) - write 100 bytes, specified by ``data'', to the server.
  4. read1000(id, buf) - read 1000 bytes from the server.
  5. write1000(id, buf) - write 1000 bytes, specified by ``data'', to the server.

We decided that we do not want to implement Intelligent Dispatching (where one thread handles NIC IO, and other "worker" threads handle computation and data manipulation) in the zeroth system. The zeroth system will consist of one thread which polls the NIC, reads incoming packets, process the data, and writes the reply packet to the wire.

The RPCs require a wire format might look like the following:

1. Input (Request packet) needs to specify:

  • server (connection id?)
  • opcode
  • struct with data buffer and length

2. Output (Reply packet) needs to specify:

  • struct (success/failure)
  • Generic Error codes
  • Op-specific information (e.g. Data to be returned on a read)
  • No labels