FakeRiak.RiakPBC (fake_riak v0.2.2)

Copy Markdown View Source

The Protocol Buffers (PBC) side of the fake Riak endpoint.

Every message is framed as <<length::32-big, msg_code::8, payload>> where length counts the code byte plus the protobuf payload. Supported messages:

CodeRequestReply
1RpbPingReq2 RpbPingResp
7RpbGetServerInfoReq8 RpbGetServerInfoResp
9RpbGetReq10 RpbGetResp (empty when absent)
11RpbPutReq12 RpbPutResp
13RpbDelReq14 RpbDelResp (always succeeds)
17RpbListKeysReq18 RpbListKeysResp (single frame)
253RpbAuthReq254 RpbAuthResp (always succeeds)
255RpbStartTls255, then a TLS handshake

Any other code gets an RpbErrorResp (0) and the connection stays open. There is no real security model: RpbAuthReq accepts any username and password (or none) and always replies with success, so clients configured for auth against a real Riak cluster still work against the fake one. Objects are stored as their raw RpbContent.value in the same bucketed FakeRiak.SimpleStore space the HTTP API uses, so the two APIs see each other's writes. Each key holds a list of siblings: an RpbPutReq without a vclock (field 3) is a blind write that appends a new sibling, while one that carries a vclock resolves the key down to the single value it sends. An RpbGetResp returns every sibling as a repeated RpbContent in field 1. Vector clocks are a static opaque token: clients only ever echo them back, so it is their presence on a put — not their content — that signals resolution.

This module is not wired to a listener itself: FakeRiak.Riak detects PBC framing on the first byte of a connection and delegates here, passing its own dispatch state through untouched (requests are independent, so no state of our own is needed).

Summary

Functions

Wrap a message code and protobuf payload in a PBC frame.

Functions

frame(code, payload)

@spec frame(0..255, iodata()) :: binary()

Wrap a message code and protobuf payload in a PBC frame.