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
breaks".
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
endian integers.
Aaron
