Protocol changes in v0.11

We’ve made some changes to the protocol in v0.11+. The diff is here.

The short summary is that

  • a few messages have Flags and Options fields added that are currently not used,
  • the field order changed slightly in the cluster config message due to this,
  • the stupid versioning has been replaced with actual version vectors, and
  • a few fields are added to the request and response messages.

@dapperstout, @vhbit, this may be relevant to your interests.

  1. Are there any estimations on when 0.11 will exit beta stage?
  2. There are no updates to protocol version but release notes for beta says that connections to 0.10 will be rejected. Does that mean that rejection is based solely on client version? If so - does it mean that other clients MUST use the same versioning scheme as syncthing?

When we feel confident-ish that it’s not completely broken. :slight_smile: I’d like to run it myself for a week or so at least first.

It’s still the unfinalized BEPv1, so no version update, no. Connections are rejected with a protocol error currently as the deserialized cluster message doesn’t make sense when interpreted from the wrong protocol perspective.

It says it will not connect to 0.10.x clients. May I assume this restriction will be lifted shortly?

No. v0.11 will never be compatible with v0.10. Hence the version bump.

@calmh I’ve digged a bit protocol changes and think that a couple of places need more explanation - to be precise the most important change and the less explained is switch from global version to counters vector. Can you elaborate a bit (with examples) on how those counters are supposed to work in terms of old global versions? or maybe in terms of vector clocks if more appropriate?

Also if Request has been changed to have an optional hash field - why not to switch completely to request a block by its hash only?

Version vectors are vector clocks, with the difference being that vector clocks are defined in terms of numbering “events” or “messages” while version vectors are bumped when a local modification is detected. The rest of the mechanics (determining what version is the newest of two, if they indeed have a parent-child relationship or are in conflict, etc) are identical.

The one extra, “local” convention we have is around conflict resolution. Since Syncthing is mostly non-interactive someone needs to “win” without asking the user. This is achieved by ordering conflicting version vectors as well, and the biggest one wins. For Syncthing, the ordering is like this - basically, the device with the lowest device ID wins. I’m not sure this needs to be implemented in exactly the same way everywhere - it might make equal or more sense to ask the user, chose by highest modification time, or something else.

We could do that… The addition here is to support the future possibility of requesting data from not fully synced files (@AudriusButkevicius work). It’s simpler as it is, as the sender only needs to open the specified file and read from the specified offset without checking the hash. Changing it requires us to have a database keyed on block hash and to verify it on read, but that’s not rocket science either.

Sorry for the late reply. I finally got around to implementing these protocol changes in Pulse Swift. They are now in the master branch:

Thanks again for the heads-up.

1 Like