aaron at serendipity.cx
Wed Feb 13 23:54:30 UTC 2008
On Feb 13, 2008, at 3:35 PM, Dustin Sallings wrote:
> On Feb 13, 2008, at 15:05, dormando wrote:
>>> I'd be up for something like that. Another verb?
>> 'caps', heh. The protocol doesn't (and shouldn't) have a handshake
>> phase though. Lets be careful to balance between "client connects
>> and does whatever it wants" vs "client connects, chooses some
>> random code path based off of the 'caps' response, and quietly
> Yeah, I suppose I don't actually *need* something like that, but
> new commands keep coming up. It'd be good to keep up with what's
> in a given server.
It'll become a de-facto handshake no matter how hard we try not to
have that happen. Where it makes sense to me is when a client library
is first given a list of servers to know about. It makes a lot of
sense to ask each server what it supports at that time.
Of course, losing a server then reconnecting and failing to check
capabilities could lead to problems. Say you try rolling in a new
memcached version, it fails, you roll back, but your clients still
think they're talking to the new code. That'd be ugly.
So capabilities would be checked on first connection, and first
connection after a connection loss.
That's great and all for TCP. What about UDP? Simple, I think: we
have to be serious about changing the magic when necessary and
throwing errors when we don't recognize field values. Clients that
don't strictly follow those rules should be beaten with sideways
More information about the memcached