Client Development Ideas (replacing libmemcached)

[dormando]

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:

1. 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).
2. 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?
3. 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.
4. 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.
5. 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.

[m6w6]

I think this list makes a lot of sense, especially 2, 3, and 5 (if it works out).

[dormando]

@m6w6 - if I may ask, what would a libmemcached replacement look like for your purposes?

[m6w6]

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!

[dormando]

@m6w6 Much appreciate you letting me know!

I'm just sitting down now to work on a revision of the core protocol handling code. Hopefully we can sync up when I'm writing the higher level bits later.