[tahoe-dev] version advertisement and negotiation

Drew Perttula drewp at bigasterisk.com
Sat Oct 18 08:17:31 UTC 2008


Brian Warner wrote:
> Reducing round trips is nice, and being able to reduce our dependence
>   
It seems like in your situation, the pattern is "meet a server once and 
then do many megabytes of traffic with it", so I don't see why 
optimizing for round trips is so important. The server can give 
something like its process id that the clients can use to tell if the 
server has just restarted with new features. If the client knows this is 
the same server process that it was talking to for the last 30 minutes, 
it can assume the feature negotiation is still valid.

The other thing that strikes me about your plan, or at least the email 
about it, is the amount of effort spent mapping protocol numbers to 
actual features. If you were relaxed about the time and bytes it takes 
to do the negotiation, I would think you'd just talk about the features 
directly instead of making everyone map them back and forth to version 
numbers. The matrix of which servers work with which clients sounds 
nice, but in practice won't it grow full of subtle caveats? E.g. 
"server3 was declared compatible with client6, until 2008-11-14 when we 
learned that the client was padding a structure that the server would 
blindly return to all clients, causing client2 to crash. So while 
server3 and client6 work fine, don't use client6 if there's a 
possibility of a client2 connecting . . ."

Next, I hope you're considering the presence of non-allmydata nodes out 
there. Your server version number shouldn't be "1.2.0r1234", since 
you're then inviting each new server to invent its own new scheme for 
versioning. At least use "allmydata-1.2.0r1234". As an RDF nut, I would 
suggest making the server versions always be URLs. Then I would go 
further and say that each negotiated feature should also be a URL. Using 
URLs makes the values really clear for debugging purposes; you can make 
them into working URLs that connect to the documentation about the 
feature; and we'll be able to search the net for any feature URL to find 
past discussions about it, etc.

This topic reminds me of the XMPP negotiation spec, although I don't 
think it adds anything significant: http://xmpp.org/extensions/xep-0020.html




More information about the tahoe-dev mailing list