Multi-Interface Patch

[Aaron Stone]

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