[tahoe-dev] version advertisement and negotiation
Drew Perttula
drewp at bigasterisk.com
Sat Oct 18 01:17:31 PDT 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