[tor-bugs] #14165 [Tor]: Tor needs a protocol versioning scheme
Tor Bug Tracker & Wiki
blackhole at torproject.org
Sun Jan 11 17:29:30 UTC 2015
#14165: Tor needs a protocol versioning scheme
-----------------------------+----------------------
Reporter: TvdW | Owner:
Type: enhancement | Status: new
Priority: normal | Milestone:
Component: Tor | Version:
Resolution: | Keywords: tor-spec
Actual Points: | Parent ID:
Points: |
-----------------------------+----------------------
Comment (by massar):
> They're nice and compact but require all alternative implementations to
implement the exact same set of features
One compare this in same way to HTML4, HTML5 etc.
> Also doesn't deal with forward compatibility well if features are
dropped in newer versions.
Should work totally fine.
eg, lets say we have:
Protocol 5 = before ntor
Protocol 6 = ntor supported
Protocol 7 = ntor, but does not support anything before P6
If the client is at P5 then it can't use P6 nodes or higher. A P7 node
won't be able to use a P6 node as it knows that itself does not have
Yes, one will have to be smart about picking features. But basically it
will mean that the protocol number is more a 'feature package' number than
an actual 'version number'.
Clients implementing higher versions will know what capabilities the older
clients do or do not have and thus if they are compatible with them.
Newer clients won't know the newer editions (though we could backport the
list of course, eg supports P5, but knows upto P8) for stable branches.
The above thus avoids the problem of having all these flags represented in
the consensus ,and a small consensus is a good consensus.
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/14165#comment:1>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
More information about the tor-bugs
mailing list