syncthing/lib/protocol/vector.go

276 lines
6.6 KiB
Go
Raw Normal View History

refactor: use modern Protobuf encoder (#9817) At a high level, this is what I've done and why: - I'm moving the protobuf generation for the `protocol`, `discovery` and `db` packages to the modern alternatives, and using `buf` to generate because it's nice and simple. - After trying various approaches on how to integrate the new types with the existing code, I opted for splitting off our own data model types from the on-the-wire generated types. This means we can have a `FileInfo` type with nicer ergonomics and lots of methods, while the protobuf generated type stays clean and close to the wire protocol. It does mean copying between the two when required, which certainly adds a small amount of inefficiency. If we want to walk this back in the future and use the raw generated type throughout, that's possible, this however makes the refactor smaller (!) as it doesn't change everything about the type for everyone at the same time. - I have simply removed in cold blood a significant number of old database migrations. These depended on previous generations of generated messages of various kinds and were annoying to support in the new fashion. The oldest supported database version now is the one from Syncthing 1.9.0 from Sep 7, 2020. - I changed config structs to be regular manually defined structs. For the sake of discussion, some things I tried that turned out not to work... ### Embedding / wrapping Embedding the protobuf generated structs in our existing types as a data container and keeping our methods and stuff: ``` package protocol type FileInfo struct { *generated.FileInfo } ``` This generates a lot of problems because the internal shape of the generated struct is quite different (different names, different types, more pointers), because initializing it doesn't work like you'd expect (i.e., you end up with an embedded nil pointer and a panic), and because the types of child types don't get wrapped. That is, even if we also have a similar wrapper around a `Vector`, that's not the type you get when accessing `someFileInfo.Version`, you get the `*generated.Vector` that doesn't have methods, etc. ### Aliasing ``` package protocol type FileInfo = generated.FileInfo ``` Doesn't help because you can't attach methods to it, plus all the above. ### Generating the types into the target package like we do now and attaching methods This fails because of the different shape of the generated type (as in the embedding case above) plus the generated struct already has a bunch of methods that we can't necessarily override properly (like `String()` and a bunch of getters). ### Methods to functions I considered just moving all the methods we attach to functions in a specific package, so that for example ``` package protocol func (f FileInfo) Equal(other FileInfo) bool ``` would become ``` package fileinfos func Equal(a, b *generated.FileInfo) bool ``` and this would mostly work, but becomes quite verbose and cumbersome, and somewhat limits discoverability (you can't see what methods are available on the type in auto completions, etc). In the end I did this in some cases, like in the database layer where a lot of things like `func (fv *FileVersion) IsEmpty() bool` becomes `func fvIsEmpty(fv *generated.FileVersion)` because they were anyway just internal methods. Fixes #8247
2024-12-01 15:50:17 +00:00
// Copyright (C) 2015 The Syncthing Authors.
//
// This Source Code Form is subject to the terms of the Mozilla Public
// License, v. 2.0. If a copy of the MPL was not distributed with this file,
// You can obtain one at https://mozilla.org/MPL/2.0/.
2015-03-20 08:58:32 +00:00
package protocol
refactor: use modern Protobuf encoder (#9817) At a high level, this is what I've done and why: - I'm moving the protobuf generation for the `protocol`, `discovery` and `db` packages to the modern alternatives, and using `buf` to generate because it's nice and simple. - After trying various approaches on how to integrate the new types with the existing code, I opted for splitting off our own data model types from the on-the-wire generated types. This means we can have a `FileInfo` type with nicer ergonomics and lots of methods, while the protobuf generated type stays clean and close to the wire protocol. It does mean copying between the two when required, which certainly adds a small amount of inefficiency. If we want to walk this back in the future and use the raw generated type throughout, that's possible, this however makes the refactor smaller (!) as it doesn't change everything about the type for everyone at the same time. - I have simply removed in cold blood a significant number of old database migrations. These depended on previous generations of generated messages of various kinds and were annoying to support in the new fashion. The oldest supported database version now is the one from Syncthing 1.9.0 from Sep 7, 2020. - I changed config structs to be regular manually defined structs. For the sake of discussion, some things I tried that turned out not to work... ### Embedding / wrapping Embedding the protobuf generated structs in our existing types as a data container and keeping our methods and stuff: ``` package protocol type FileInfo struct { *generated.FileInfo } ``` This generates a lot of problems because the internal shape of the generated struct is quite different (different names, different types, more pointers), because initializing it doesn't work like you'd expect (i.e., you end up with an embedded nil pointer and a panic), and because the types of child types don't get wrapped. That is, even if we also have a similar wrapper around a `Vector`, that's not the type you get when accessing `someFileInfo.Version`, you get the `*generated.Vector` that doesn't have methods, etc. ### Aliasing ``` package protocol type FileInfo = generated.FileInfo ``` Doesn't help because you can't attach methods to it, plus all the above. ### Generating the types into the target package like we do now and attaching methods This fails because of the different shape of the generated type (as in the embedding case above) plus the generated struct already has a bunch of methods that we can't necessarily override properly (like `String()` and a bunch of getters). ### Methods to functions I considered just moving all the methods we attach to functions in a specific package, so that for example ``` package protocol func (f FileInfo) Equal(other FileInfo) bool ``` would become ``` package fileinfos func Equal(a, b *generated.FileInfo) bool ``` and this would mostly work, but becomes quite verbose and cumbersome, and somewhat limits discoverability (you can't see what methods are available on the type in auto completions, etc). In the end I did this in some cases, like in the database layer where a lot of things like `func (fv *FileVersion) IsEmpty() bool` becomes `func fvIsEmpty(fv *generated.FileVersion)` because they were anyway just internal methods. Fixes #8247
2024-12-01 15:50:17 +00:00
import (
"time"
"github.com/syncthing/syncthing/internal/gen/bep"
)
2015-09-22 19:51:05 +00:00
// The Vector type represents a version vector. The zero value is a usable
2015-03-20 08:58:32 +00:00
// version vector. The vector has slice semantics and some operations on it
2015-09-22 18:34:24 +00:00
// are "append-like" in that they may return the same vector modified, or v
2015-03-20 08:58:32 +00:00
// new allocated Vector with the modified contents.
refactor: use modern Protobuf encoder (#9817) At a high level, this is what I've done and why: - I'm moving the protobuf generation for the `protocol`, `discovery` and `db` packages to the modern alternatives, and using `buf` to generate because it's nice and simple. - After trying various approaches on how to integrate the new types with the existing code, I opted for splitting off our own data model types from the on-the-wire generated types. This means we can have a `FileInfo` type with nicer ergonomics and lots of methods, while the protobuf generated type stays clean and close to the wire protocol. It does mean copying between the two when required, which certainly adds a small amount of inefficiency. If we want to walk this back in the future and use the raw generated type throughout, that's possible, this however makes the refactor smaller (!) as it doesn't change everything about the type for everyone at the same time. - I have simply removed in cold blood a significant number of old database migrations. These depended on previous generations of generated messages of various kinds and were annoying to support in the new fashion. The oldest supported database version now is the one from Syncthing 1.9.0 from Sep 7, 2020. - I changed config structs to be regular manually defined structs. For the sake of discussion, some things I tried that turned out not to work... ### Embedding / wrapping Embedding the protobuf generated structs in our existing types as a data container and keeping our methods and stuff: ``` package protocol type FileInfo struct { *generated.FileInfo } ``` This generates a lot of problems because the internal shape of the generated struct is quite different (different names, different types, more pointers), because initializing it doesn't work like you'd expect (i.e., you end up with an embedded nil pointer and a panic), and because the types of child types don't get wrapped. That is, even if we also have a similar wrapper around a `Vector`, that's not the type you get when accessing `someFileInfo.Version`, you get the `*generated.Vector` that doesn't have methods, etc. ### Aliasing ``` package protocol type FileInfo = generated.FileInfo ``` Doesn't help because you can't attach methods to it, plus all the above. ### Generating the types into the target package like we do now and attaching methods This fails because of the different shape of the generated type (as in the embedding case above) plus the generated struct already has a bunch of methods that we can't necessarily override properly (like `String()` and a bunch of getters). ### Methods to functions I considered just moving all the methods we attach to functions in a specific package, so that for example ``` package protocol func (f FileInfo) Equal(other FileInfo) bool ``` would become ``` package fileinfos func Equal(a, b *generated.FileInfo) bool ``` and this would mostly work, but becomes quite verbose and cumbersome, and somewhat limits discoverability (you can't see what methods are available on the type in auto completions, etc). In the end I did this in some cases, like in the database layer where a lot of things like `func (fv *FileVersion) IsEmpty() bool` becomes `func fvIsEmpty(fv *generated.FileVersion)` because they were anyway just internal methods. Fixes #8247
2024-12-01 15:50:17 +00:00
type Vector struct {
Counters []Counter
}
func (v *Vector) ToWire() *bep.Vector {
counters := make([]*bep.Counter, len(v.Counters))
for i, c := range v.Counters {
counters[i] = c.toWire()
}
return &bep.Vector{
Counters: counters,
}
}
func VectorFromWire(w *bep.Vector) Vector {
var v Vector
if w == nil || len(w.Counters) == 0 {
return v
}
v.Counters = make([]Counter, len(w.Counters))
for i, c := range w.Counters {
v.Counters[i] = counterFromWire(c)
}
return v
}
2015-03-20 08:58:32 +00:00
2015-09-22 19:51:05 +00:00
// Counter represents a single counter in the version vector.
refactor: use modern Protobuf encoder (#9817) At a high level, this is what I've done and why: - I'm moving the protobuf generation for the `protocol`, `discovery` and `db` packages to the modern alternatives, and using `buf` to generate because it's nice and simple. - After trying various approaches on how to integrate the new types with the existing code, I opted for splitting off our own data model types from the on-the-wire generated types. This means we can have a `FileInfo` type with nicer ergonomics and lots of methods, while the protobuf generated type stays clean and close to the wire protocol. It does mean copying between the two when required, which certainly adds a small amount of inefficiency. If we want to walk this back in the future and use the raw generated type throughout, that's possible, this however makes the refactor smaller (!) as it doesn't change everything about the type for everyone at the same time. - I have simply removed in cold blood a significant number of old database migrations. These depended on previous generations of generated messages of various kinds and were annoying to support in the new fashion. The oldest supported database version now is the one from Syncthing 1.9.0 from Sep 7, 2020. - I changed config structs to be regular manually defined structs. For the sake of discussion, some things I tried that turned out not to work... ### Embedding / wrapping Embedding the protobuf generated structs in our existing types as a data container and keeping our methods and stuff: ``` package protocol type FileInfo struct { *generated.FileInfo } ``` This generates a lot of problems because the internal shape of the generated struct is quite different (different names, different types, more pointers), because initializing it doesn't work like you'd expect (i.e., you end up with an embedded nil pointer and a panic), and because the types of child types don't get wrapped. That is, even if we also have a similar wrapper around a `Vector`, that's not the type you get when accessing `someFileInfo.Version`, you get the `*generated.Vector` that doesn't have methods, etc. ### Aliasing ``` package protocol type FileInfo = generated.FileInfo ``` Doesn't help because you can't attach methods to it, plus all the above. ### Generating the types into the target package like we do now and attaching methods This fails because of the different shape of the generated type (as in the embedding case above) plus the generated struct already has a bunch of methods that we can't necessarily override properly (like `String()` and a bunch of getters). ### Methods to functions I considered just moving all the methods we attach to functions in a specific package, so that for example ``` package protocol func (f FileInfo) Equal(other FileInfo) bool ``` would become ``` package fileinfos func Equal(a, b *generated.FileInfo) bool ``` and this would mostly work, but becomes quite verbose and cumbersome, and somewhat limits discoverability (you can't see what methods are available on the type in auto completions, etc). In the end I did this in some cases, like in the database layer where a lot of things like `func (fv *FileVersion) IsEmpty() bool` becomes `func fvIsEmpty(fv *generated.FileVersion)` because they were anyway just internal methods. Fixes #8247
2024-12-01 15:50:17 +00:00
type Counter struct {
ID ShortID
Value uint64
}
func (c *Counter) toWire() *bep.Counter {
return &bep.Counter{
Id: uint64(c.ID),
Value: c.Value,
}
}
func counterFromWire(w *bep.Counter) Counter {
return Counter{
ID: ShortID(w.Id),
Value: w.Value,
}
}
2015-03-20 08:58:32 +00:00
2015-09-22 19:51:05 +00:00
// Update returns a Vector with the index for the specific ID incremented by
2015-03-20 08:58:32 +00:00
// one. If it is possible, the vector v is updated and returned. If it is not,
2015-09-22 19:51:05 +00:00
// a copy will be created, updated and returned.
func (v Vector) Update(id ShortID) Vector {
now := uint64(time.Now().Unix())
return v.updateWithNow(id, now)
}
func (v Vector) updateWithNow(id ShortID, now uint64) Vector {
for i := range v.Counters {
if v.Counters[i].ID == id {
2015-03-20 08:58:32 +00:00
// Update an existing index
v.Counters[i].Value = max(v.Counters[i].Value+1, now)
2015-03-20 08:58:32 +00:00
return v
} else if v.Counters[i].ID > id {
2015-09-22 19:51:05 +00:00
// Insert a new index
nv := make([]Counter, len(v.Counters)+1)
copy(nv, v.Counters[:i])
nv[i].ID = id
nv[i].Value = max(1, now)
copy(nv[i+1:], v.Counters[i:])
return Vector{Counters: nv}
2015-03-20 08:58:32 +00:00
}
}
2015-09-22 19:51:05 +00:00
// Append a new index
return Vector{Counters: append(v.Counters, Counter{
ID: id,
Value: max(1, now),
})}
}
2015-09-22 18:34:24 +00:00
// Merge returns the vector containing the maximum indexes from v and b. If it
2015-09-22 19:51:05 +00:00
// is possible, the vector v is updated and returned. If it is not, a copy
2015-03-20 08:58:32 +00:00
// will be created, updated and returned.
2015-09-22 18:34:24 +00:00
func (v Vector) Merge(b Vector) Vector {
var vi, bi int
for bi < len(b.Counters) {
if vi == len(v.Counters) {
2015-09-22 18:34:24 +00:00
// We've reach the end of v, all that remains are appends
return Vector{Counters: append(v.Counters, b.Counters[bi:]...)}
2015-03-20 08:58:32 +00:00
}
if v.Counters[vi].ID > b.Counters[bi].ID {
2015-03-20 08:58:32 +00:00
// The index from b should be inserted here
n := make([]Counter, len(v.Counters)+1)
copy(n, v.Counters[:vi])
n[vi] = b.Counters[bi]
copy(n[vi+1:], v.Counters[vi:])
v.Counters = n
2015-03-20 08:58:32 +00:00
}
if v.Counters[vi].ID == b.Counters[bi].ID {
if val := b.Counters[bi].Value; val > v.Counters[vi].Value {
v.Counters[vi].Value = val
2015-03-20 08:58:32 +00:00
}
}
if bi < len(b.Counters) && v.Counters[vi].ID == b.Counters[bi].ID {
2015-03-20 08:58:32 +00:00
bi++
}
2015-09-22 18:34:24 +00:00
vi++
2015-03-20 08:58:32 +00:00
}
2015-09-22 18:34:24 +00:00
return v
2015-03-20 08:58:32 +00:00
}
// Copy returns an identical vector that is not shared with v.
func (v Vector) Copy() Vector {
nv := make([]Counter, len(v.Counters))
copy(nv, v.Counters)
return Vector{Counters: nv}
2015-03-20 08:58:32 +00:00
}
// Equal returns true when the two vectors are equivalent.
2015-09-22 18:34:24 +00:00
func (v Vector) Equal(b Vector) bool {
return v.Compare(b) == Equal
2015-03-20 08:58:32 +00:00
}
2015-09-22 18:34:24 +00:00
// LesserEqual returns true when the two vectors are equivalent or v is Lesser
2015-03-20 08:58:32 +00:00
// than b.
2015-09-22 18:34:24 +00:00
func (v Vector) LesserEqual(b Vector) bool {
comp := v.Compare(b)
2015-03-20 08:58:32 +00:00
return comp == Lesser || comp == Equal
}
2015-09-22 18:34:24 +00:00
// GreaterEqual returns true when the two vectors are equivalent or v is Greater
2015-03-20 08:58:32 +00:00
// than b.
2015-09-22 18:34:24 +00:00
func (v Vector) GreaterEqual(b Vector) bool {
comp := v.Compare(b)
2015-03-20 08:58:32 +00:00
return comp == Greater || comp == Equal
}
// Concurrent returns true when the two vectors are concurrent.
2015-09-22 18:34:24 +00:00
func (v Vector) Concurrent(b Vector) bool {
comp := v.Compare(b)
2015-03-20 08:58:32 +00:00
return comp == ConcurrentGreater || comp == ConcurrentLesser
}
2015-04-09 10:51:21 +00:00
// Counter returns the current value of the given counter ID.
func (v Vector) Counter(id ShortID) uint64 {
for _, c := range v.Counters {
2015-04-09 10:51:21 +00:00
if c.ID == id {
return c.Value
}
}
return 0
}
// IsEmpty returns true when there are no counters.
func (v Vector) IsEmpty() bool {
return len(v.Counters) == 0
}
// DropOthers removes all counters, keeping only the one with given id. If there
// is no such counter, an empty Vector is returned.
func (v Vector) DropOthers(id ShortID) Vector {
for i, c := range v.Counters {
if c.ID == id {
v.Counters = v.Counters[i : i+1]
return v
}
}
return Vector{}
}
// Ordering represents the relationship between two Vectors.
type Ordering int
const (
Equal Ordering = iota
Greater
Lesser
ConcurrentLesser
ConcurrentGreater
)
// There's really no such thing as "concurrent lesser" and "concurrent
// greater" in version vectors, just "concurrent". But it's useful to be able
// to get a strict ordering between versions for stable sorts and so on, so we
// return both variants. The convenience method Concurrent() can be used to
// check for either case.
// Compare returns the Ordering that describes a's relation to b.
func (v Vector) Compare(b Vector) Ordering {
var ai, bi int // index into a and b
var av, bv Counter // value at current index
result := Equal
for ai < len(v.Counters) || bi < len(b.Counters) {
var aMissing, bMissing bool
if ai < len(v.Counters) {
av = v.Counters[ai]
} else {
av = Counter{}
aMissing = true
}
if bi < len(b.Counters) {
bv = b.Counters[bi]
} else {
bv = Counter{}
bMissing = true
}
switch {
case av.ID == bv.ID:
// We have a counter value for each side
if av.Value > bv.Value {
if result == Lesser {
return ConcurrentLesser
}
result = Greater
} else if av.Value < bv.Value {
if result == Greater {
return ConcurrentGreater
}
result = Lesser
}
case !aMissing && av.ID < bv.ID || bMissing:
// Value is missing on the b side
if av.Value > 0 {
if result == Lesser {
return ConcurrentLesser
}
result = Greater
}
case !bMissing && bv.ID < av.ID || aMissing:
// Value is missing on the a side
if bv.Value > 0 {
if result == Greater {
return ConcurrentGreater
}
result = Lesser
}
}
if ai < len(v.Counters) && (av.ID <= bv.ID || bMissing) {
ai++
}
if bi < len(b.Counters) && (bv.ID <= av.ID || aMissing) {
bi++
}
}
return result
}