Tomash Brechko wrote:
In current text protocol there's no way to know the size of the reply, and command replies vary. Once run_command() is a generic interface, it should be possible to call it for any command. Butrun_command("get foo\r\n"); may contain _any_ character sequence in the reply, including "END" and friends. And if run_command() will be made aware of the protocol details, it won't be generic and forward compatible any longer. In other words, it's impossible to write a transparent proxy with current protocol. Given that it's broken anyway, shouldn't we deprecate it, and remove in the future?
I wrote a memcache proxy a while ago, and you're right, it does need to understand the protocol. It really wasn't that hard to write though, since the protocol is so simple. I wrote it in php in a day as a proof of concept, event based, complete with connection sharing and request pipelining, and possibly request combining (ie several gets combined to one multi-get). I think it may even have done the hashing itself, so from the clients perspective, we'd just have one memcached server. Despite being only a proof of concept, written in php and needing to know the protocol, it turned out to be surprisingly fast. If we ever get to the point that we need too many persistent connections for memcached to handle, and for some reason we reject the udp protocol, I wouldn't hesitate to revive that project, and possibly even put the php version live for a couple days/weeks while we rewrite it in C (ie so we can use epoll instead of select, can do fewer memory copies, faster, etc).
Timo
