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:
| Code | Request | Reply |
|---|---|---|
| 1 | RpbPingReq | 2 RpbPingResp |
| 7 | RpbGetServerInfoReq | 8 RpbGetServerInfoResp |
| 9 | RpbGetReq | 10 RpbGetResp (empty when absent) |
| 11 | RpbPutReq | 12 RpbPutResp |
| 13 | RpbDelReq | 14 RpbDelResp (always succeeds) |
| 17 | RpbListKeysReq | 18 RpbListKeysResp (single frame) |
| 253 | RpbAuthReq | 254 RpbAuthResp (always succeeds) |
| 255 | RpbStartTls | 255, 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.