Client Development Ideas (replacing libmemcached)
dormando opened this issue · comments
I want to turn mcmc, or something that embeds mcmc, into something that replaces libmemcached. Not 1:1 with features but enough for modern feature coverage.
I wrote an initial version of mcmc a few years ago, which is mostly just a response parser. I've been using it in the new internal proxy code and now https://github.com/memcached/mcshredder - what I need to do next is figure out how to expand this into a full client, and find out what "replacing libmemcached" means to people.
My loose goals:
- Create a minimized client. ie; while I may add server (request) protocol parsing, it won't have an expansive feature list, no built-in bench tool, no binary protocol support, focus on meta protocol, etc. This should leverage the generic response parser to minimize code (ie; no matter what you send down the pipe it's the same code to parse the response).
- Work well with event loops and io_uring, which means a layer of "wait for an fd event" as well as "caller handles syscalls" (which is trickier). So far as I know libmemcached does its own poll/select/etc and you can't even use epoll?
- Minimize the hash/server selector code: we should support xxhash + jumphash and md5/ketama (weightless), and anything else should be pluggable. I noticed a lot of clients had key distribution bugs by adding weights to ketama/etc.
- Ideally this creates a specification for how to build clients. ie; Go, Java, Rust, etc aren't going to embed a C library, but if we can say "if you implement X/Y/Z like this you've got a 100% compatible memcached client and here's the reference code" I imagine that would help people.
- Internally alloc-free is a pretty good goal; at very least the core should stay this way. Libmemcached does a lot of malloc/free'ing so far as I can tell, and that's tough on high performance situations.
Unknowns:
- I'm not super great at writing client code so I'd feel more confident if I could work with people who work with libmemcached more :)
- Libmemcached is huge and it's unclear how much or what of it is important to people.
- It's unclear if we need a "libmemcached compatibility layer" to make porting easier. I'd be happy to include this if it weren't huge.
I think this list makes a lot of sense, especially 2, 3, and 5 (if it works out).
@m6w6 - if I may ask, what would a libmemcached replacement look like for your purposes?
Hey @dormando, just to let you know, I didn't ghost that topic; it's just, there was a lot going on for me, so hopefully I'll have time to revisit this in this summer!