WARNING: WORK IN PROGRESS. Missing features or testing!
MCMC is a minimalistic allocation-free modern client for memcached. It uses a generic response parser, allowing a single code path regardless of the command sent to memcached. It has no 3rd party dependencies and is designed to integrate as a building block into full clients.
MCMC does not (yet) include a typical memcached "selector". Meaning the ability to add many servers to a hash table of some kind and routing keys to specific servers. The MCMC base client is designed to be an object that selector objects hold and then issue commands against.
Allocation-free (aside from a call to getaddrinfo()) means it does not
internally do any allocations, relying only on the stack. It requires you
malloc a small structure and some buffers, but you are then free to manage
them yourselves. Clients do not hold onto buffers when idle, cutting their
memory overhead to a handful of bytes plus the TCP socket.
MCMC is designed to be a building block for users designing full clients. For example:
- A client author wants to implement the "get" command
- They write a function in their native language's wrapper which accepts the
key to fetch and embeds that into a text buffer to look like
get [key]\r\n - They then call mcmc's functions to send and read the response, parsing and returning it to the client.
This should be the same, if not less, code than wrapping a full C client with every possible command broken out. It also means 3rd party clients can (and should!) embed mcmc.c/mcmc.h (and any selector code they want) rather than be dependent on system distribution of a more complex client.
The allocation-free nature also makes unit testing the client code easier, hopefully leading to higher quality.
Caveats:
- Care should be taken when handling the buffers mcmc requires to operate. Since there are few operators you should only have to pay attention once :)
- It does not support the various maintenance/settings commands (ie;
lru_crawler). It may gain some generic support for this, but those commands were not designed with consistent response codes and are hard to implement. - Does not support the binary protocol, which has been deprecated as of 1.6.0.
As of this writing the code is being released early (perhaps too early?). It may not have proper makefiles, tests, or a fully implemented API. The code has been posted so client authors and users can give early feedback on the API in hopes of prodiving something high quality and stable.
Again, looking for feedback! Open an issue or let me know what you think.