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) 2014 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/.
|
2014-09-22 19:42:11 +00:00
|
|
|
|
|
|
|
package protocol
|
|
|
|
|
|
|
|
import (
|
2016-07-04 10:40:29 +00:00
|
|
|
"bytes"
|
2019-11-19 08:56:53 +00:00
|
|
|
"context"
|
2018-06-06 07:59:33 +00:00
|
|
|
"encoding/hex"
|
2014-09-22 19:42:11 +00:00
|
|
|
"encoding/json"
|
2016-01-12 08:19:44 +00:00
|
|
|
"errors"
|
2014-09-22 19:42:11 +00:00
|
|
|
"io"
|
2021-11-22 07:59:47 +00:00
|
|
|
"os"
|
2019-05-23 20:42:02 +00:00
|
|
|
"sync"
|
2014-09-22 19:42:11 +00:00
|
|
|
"testing"
|
2019-05-23 20:42:02 +00:00
|
|
|
"time"
|
2014-09-22 19:42:11 +00:00
|
|
|
|
2022-01-17 17:52:43 +00:00
|
|
|
lz4 "github.com/pierrec/lz4/v4"
|
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
|
|
|
"google.golang.org/protobuf/proto"
|
|
|
|
|
|
|
|
"github.com/syncthing/syncthing/internal/gen/bep"
|
2016-07-04 10:40:29 +00:00
|
|
|
"github.com/syncthing/syncthing/lib/rand"
|
2023-08-21 17:44:33 +00:00
|
|
|
"github.com/syncthing/syncthing/lib/testutil"
|
2014-09-22 19:42:11 +00:00
|
|
|
)
|
|
|
|
|
|
|
|
var (
|
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
|
|
|
c0ID = NewDeviceID([]byte{1})
|
|
|
|
c1ID = NewDeviceID([]byte{2})
|
2014-09-22 19:42:11 +00:00
|
|
|
)
|
|
|
|
|
|
|
|
func TestPing(t *testing.T) {
|
|
|
|
ar, aw := io.Pipe()
|
|
|
|
br, bw := io.Pipe()
|
|
|
|
|
2023-08-21 17:44:33 +00:00
|
|
|
c0 := getRawConnection(NewConnection(c0ID, ar, bw, testutil.NoopCloser{}, newTestModel(), new(mockedConnectionInfo), CompressionAlways, nil, testKeyGen))
|
2015-07-10 06:34:54 +00:00
|
|
|
c0.Start()
|
2020-11-27 10:31:20 +00:00
|
|
|
defer closeAndWait(c0, ar, bw)
|
2023-08-21 17:44:33 +00:00
|
|
|
c1 := getRawConnection(NewConnection(c1ID, br, aw, testutil.NoopCloser{}, newTestModel(), new(mockedConnectionInfo), CompressionAlways, nil, testKeyGen))
|
2015-07-10 06:34:54 +00:00
|
|
|
c1.Start()
|
2020-11-27 10:31:20 +00:00
|
|
|
defer closeAndWait(c1, ar, bw)
|
2024-08-24 10:45:10 +00:00
|
|
|
c0.ClusterConfig(&ClusterConfig{})
|
|
|
|
c1.ClusterConfig(&ClusterConfig{})
|
2014-09-22 19:42:11 +00:00
|
|
|
|
|
|
|
if ok := c0.ping(); !ok {
|
|
|
|
t.Error("c0 ping failed")
|
|
|
|
}
|
|
|
|
if ok := c1.ping(); !ok {
|
|
|
|
t.Error("c1 ping failed")
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2019-05-23 20:42:02 +00:00
|
|
|
var errManual = errors.New("manual close")
|
|
|
|
|
2014-09-22 19:42:11 +00:00
|
|
|
func TestClose(t *testing.T) {
|
|
|
|
m0 := newTestModel()
|
|
|
|
m1 := newTestModel()
|
|
|
|
|
|
|
|
ar, aw := io.Pipe()
|
|
|
|
br, bw := io.Pipe()
|
|
|
|
|
2023-08-21 17:44:33 +00:00
|
|
|
c0 := getRawConnection(NewConnection(c0ID, ar, bw, testutil.NoopCloser{}, m0, new(mockedConnectionInfo), CompressionAlways, nil, testKeyGen))
|
2015-07-10 06:34:54 +00:00
|
|
|
c0.Start()
|
2020-11-27 10:31:20 +00:00
|
|
|
defer closeAndWait(c0, ar, bw)
|
2023-08-21 17:44:33 +00:00
|
|
|
c1 := NewConnection(c1ID, br, aw, testutil.NoopCloser{}, m1, new(mockedConnectionInfo), CompressionAlways, nil, testKeyGen)
|
2015-07-10 06:34:54 +00:00
|
|
|
c1.Start()
|
2020-11-27 10:31:20 +00:00
|
|
|
defer closeAndWait(c1, ar, bw)
|
2024-08-24 10:45:10 +00:00
|
|
|
c0.ClusterConfig(&ClusterConfig{})
|
|
|
|
c1.ClusterConfig(&ClusterConfig{})
|
2014-09-22 19:42:11 +00:00
|
|
|
|
2019-05-23 20:42:02 +00:00
|
|
|
c0.internalClose(errManual)
|
2014-09-22 19:42:11 +00:00
|
|
|
|
|
|
|
<-c0.closed
|
2019-05-23 20:42:02 +00:00
|
|
|
if err := m0.closedError(); err != errManual {
|
2014-09-22 19:42:11 +00:00
|
|
|
t.Fatal("Connection should be closed")
|
|
|
|
}
|
|
|
|
|
|
|
|
// None of these should panic, some should return an error
|
|
|
|
|
|
|
|
if c0.ping() {
|
|
|
|
t.Error("Ping should not return true")
|
|
|
|
}
|
|
|
|
|
2019-11-25 10:07:36 +00:00
|
|
|
ctx := context.Background()
|
2014-09-22 19:42:11 +00:00
|
|
|
|
2024-08-24 10:45:10 +00:00
|
|
|
c0.Index(ctx, &Index{Folder: "default"})
|
|
|
|
c0.Index(ctx, &Index{Folder: "default"})
|
2019-11-25 10:07:36 +00:00
|
|
|
|
2024-08-24 10:45:10 +00:00
|
|
|
if _, err := c0.Request(ctx, &Request{Folder: "default", Name: "foo"}); err == nil {
|
2014-09-22 19:42:11 +00:00
|
|
|
t.Error("Request should return an error")
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2019-05-23 20:42:02 +00:00
|
|
|
// TestCloseOnBlockingSend checks that the connection does not deadlock when
|
|
|
|
// Close is called while the underlying connection is broken (send blocks).
|
|
|
|
// https://github.com/syncthing/syncthing/pull/5442
|
|
|
|
func TestCloseOnBlockingSend(t *testing.T) {
|
2019-06-05 06:01:59 +00:00
|
|
|
oldCloseTimeout := CloseTimeout
|
|
|
|
CloseTimeout = 100 * time.Millisecond
|
|
|
|
defer func() {
|
|
|
|
CloseTimeout = oldCloseTimeout
|
|
|
|
}()
|
|
|
|
|
2019-05-23 20:42:02 +00:00
|
|
|
m := newTestModel()
|
|
|
|
|
2023-08-21 17:44:33 +00:00
|
|
|
rw := testutil.NewBlockingRW()
|
|
|
|
c := getRawConnection(NewConnection(c0ID, rw, rw, testutil.NoopCloser{}, m, new(mockedConnectionInfo), CompressionAlways, nil, testKeyGen))
|
2019-05-23 20:42:02 +00:00
|
|
|
c.Start()
|
2020-11-27 10:31:20 +00:00
|
|
|
defer closeAndWait(c, rw)
|
2019-05-23 20:42:02 +00:00
|
|
|
|
|
|
|
wg := sync.WaitGroup{}
|
|
|
|
|
|
|
|
wg.Add(1)
|
|
|
|
go func() {
|
2024-08-24 10:45:10 +00:00
|
|
|
c.ClusterConfig(&ClusterConfig{})
|
2019-05-23 20:42:02 +00:00
|
|
|
wg.Done()
|
|
|
|
}()
|
|
|
|
|
|
|
|
wg.Add(1)
|
|
|
|
go func() {
|
|
|
|
c.Close(errManual)
|
|
|
|
wg.Done()
|
|
|
|
}()
|
|
|
|
|
|
|
|
// This simulates an error from ping timeout
|
|
|
|
wg.Add(1)
|
|
|
|
go func() {
|
|
|
|
c.internalClose(ErrTimeout)
|
|
|
|
wg.Done()
|
|
|
|
}()
|
|
|
|
|
|
|
|
done := make(chan struct{})
|
|
|
|
go func() {
|
|
|
|
wg.Wait()
|
|
|
|
close(done)
|
|
|
|
}()
|
|
|
|
|
|
|
|
select {
|
|
|
|
case <-done:
|
|
|
|
case <-time.After(time.Second):
|
|
|
|
t.Fatal("timed out before all functions returned")
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2019-05-25 19:08:07 +00:00
|
|
|
func TestCloseRace(t *testing.T) {
|
|
|
|
indexReceived := make(chan struct{})
|
|
|
|
unblockIndex := make(chan struct{})
|
|
|
|
m0 := newTestModel()
|
2023-07-29 08:24:44 +00:00
|
|
|
m0.indexFn = func(string, []FileInfo) {
|
2019-05-25 19:08:07 +00:00
|
|
|
close(indexReceived)
|
|
|
|
<-unblockIndex
|
|
|
|
}
|
|
|
|
m1 := newTestModel()
|
|
|
|
|
|
|
|
ar, aw := io.Pipe()
|
|
|
|
br, bw := io.Pipe()
|
|
|
|
|
2023-08-21 17:44:33 +00:00
|
|
|
c0 := getRawConnection(NewConnection(c0ID, ar, bw, testutil.NoopCloser{}, m0, new(mockedConnectionInfo), CompressionNever, nil, testKeyGen))
|
2019-05-25 19:08:07 +00:00
|
|
|
c0.Start()
|
2020-11-27 10:31:20 +00:00
|
|
|
defer closeAndWait(c0, ar, bw)
|
2023-08-21 17:44:33 +00:00
|
|
|
c1 := NewConnection(c1ID, br, aw, testutil.NoopCloser{}, m1, new(mockedConnectionInfo), CompressionNever, nil, testKeyGen)
|
2019-05-25 19:08:07 +00:00
|
|
|
c1.Start()
|
2020-11-27 10:31:20 +00:00
|
|
|
defer closeAndWait(c1, ar, bw)
|
2024-08-24 10:45:10 +00:00
|
|
|
c0.ClusterConfig(&ClusterConfig{})
|
|
|
|
c1.ClusterConfig(&ClusterConfig{})
|
2019-05-25 19:08:07 +00:00
|
|
|
|
2024-08-24 10:45:10 +00:00
|
|
|
c1.Index(context.Background(), &Index{Folder: "default"})
|
2019-05-25 19:08:07 +00:00
|
|
|
select {
|
|
|
|
case <-indexReceived:
|
|
|
|
case <-time.After(time.Second):
|
|
|
|
t.Fatal("timed out before receiving index")
|
|
|
|
}
|
|
|
|
|
|
|
|
go c0.internalClose(errManual)
|
|
|
|
select {
|
|
|
|
case <-c0.closed:
|
|
|
|
case <-time.After(time.Second):
|
|
|
|
t.Fatal("timed out before c0.closed was closed")
|
|
|
|
}
|
|
|
|
|
|
|
|
select {
|
|
|
|
case <-m0.closedCh:
|
|
|
|
t.Errorf("receiver.Closed called before receiver.Index")
|
|
|
|
default:
|
|
|
|
}
|
|
|
|
|
|
|
|
close(unblockIndex)
|
|
|
|
|
|
|
|
if err := m0.closedError(); err != errManual {
|
|
|
|
t.Fatal("Connection should be closed")
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2019-05-27 10:15:34 +00:00
|
|
|
func TestClusterConfigFirst(t *testing.T) {
|
|
|
|
m := newTestModel()
|
|
|
|
|
2023-08-21 17:44:33 +00:00
|
|
|
rw := testutil.NewBlockingRW()
|
|
|
|
c := getRawConnection(NewConnection(c0ID, rw, &testutil.NoopRW{}, testutil.NoopCloser{}, m, new(mockedConnectionInfo), CompressionAlways, nil, testKeyGen))
|
2019-05-27 10:15:34 +00:00
|
|
|
c.Start()
|
2020-11-27 10:31:20 +00:00
|
|
|
defer closeAndWait(c, rw)
|
2019-05-27 10:15:34 +00:00
|
|
|
|
|
|
|
select {
|
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
|
|
|
case c.outbox <- asyncMessage{&bep.Ping{}, nil}:
|
2019-05-27 10:15:34 +00:00
|
|
|
t.Fatal("able to send ping before cluster config")
|
|
|
|
case <-time.After(100 * time.Millisecond):
|
|
|
|
// Allow some time for c.writerLoop to setup after c.Start
|
|
|
|
}
|
|
|
|
|
2024-08-24 10:45:10 +00:00
|
|
|
c.ClusterConfig(&ClusterConfig{})
|
2019-05-27 10:15:34 +00:00
|
|
|
|
|
|
|
done := make(chan struct{})
|
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
|
|
|
if ok := c.send(context.Background(), &bep.Ping{}, done); !ok {
|
2019-05-27 10:15:34 +00:00
|
|
|
t.Fatal("send ping after cluster config returned false")
|
|
|
|
}
|
|
|
|
select {
|
|
|
|
case <-done:
|
|
|
|
case <-time.After(time.Second):
|
|
|
|
t.Fatal("timed out before ping was sent")
|
|
|
|
}
|
|
|
|
|
|
|
|
done = make(chan struct{})
|
|
|
|
go func() {
|
|
|
|
c.internalClose(errManual)
|
|
|
|
close(done)
|
|
|
|
}()
|
|
|
|
|
|
|
|
select {
|
|
|
|
case <-done:
|
|
|
|
case <-time.After(5 * time.Second):
|
|
|
|
t.Fatal("Close didn't return before timeout")
|
|
|
|
}
|
|
|
|
|
|
|
|
if err := m.closedError(); err != errManual {
|
|
|
|
t.Fatal("Connection should be closed")
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2019-06-05 06:01:59 +00:00
|
|
|
// TestCloseTimeout checks that calling Close times out and proceeds, if sending
|
|
|
|
// the close message does not succeed.
|
|
|
|
func TestCloseTimeout(t *testing.T) {
|
|
|
|
oldCloseTimeout := CloseTimeout
|
|
|
|
CloseTimeout = 100 * time.Millisecond
|
|
|
|
defer func() {
|
|
|
|
CloseTimeout = oldCloseTimeout
|
|
|
|
}()
|
|
|
|
|
|
|
|
m := newTestModel()
|
|
|
|
|
2023-08-21 17:44:33 +00:00
|
|
|
rw := testutil.NewBlockingRW()
|
|
|
|
c := getRawConnection(NewConnection(c0ID, rw, rw, testutil.NoopCloser{}, m, new(mockedConnectionInfo), CompressionAlways, nil, testKeyGen))
|
2019-06-05 06:01:59 +00:00
|
|
|
c.Start()
|
2020-11-27 10:31:20 +00:00
|
|
|
defer closeAndWait(c, rw)
|
2019-06-05 06:01:59 +00:00
|
|
|
|
|
|
|
done := make(chan struct{})
|
|
|
|
go func() {
|
|
|
|
c.Close(errManual)
|
|
|
|
close(done)
|
|
|
|
}()
|
|
|
|
|
|
|
|
select {
|
|
|
|
case <-done:
|
|
|
|
case <-time.After(5 * CloseTimeout):
|
|
|
|
t.Fatal("timed out before Close returned")
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2017-01-01 17:19:00 +00:00
|
|
|
func TestUnmarshalFDPUv16v17(t *testing.T) {
|
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
|
|
|
var fdpu bep.FileDownloadProgressUpdate
|
2017-01-01 17:19:00 +00:00
|
|
|
|
|
|
|
m0, _ := hex.DecodeString("08cda1e2e3011278f3918787f3b89b8af2958887f0aa9389f3a08588f3aa8f96f39aa8a5f48b9188f19286a0f3848da4f3aba799f3beb489f0a285b9f487b684f2a3bda2f48598b4f2938a89f2a28badf187a0a2f2aebdbdf4849494f4808fbbf2b3a2adf2bb95bff0a6ada4f198ab9af29a9c8bf1abb793f3baabb2f188a6ba1a0020bb9390f60220f6d9e42220b0c7e2b2fdffffffff0120fdb2dfcdfbffffffff0120cedab1d50120bd8784c0feffffffff0120ace99591fdffffffff0120eed7d09af9ffffffff01")
|
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
|
|
|
if err := proto.Unmarshal(m0, &fdpu); err != nil {
|
2017-01-01 17:19:00 +00:00
|
|
|
t.Fatal("Unmarshalling message from v0.14.16:", err)
|
|
|
|
}
|
|
|
|
|
|
|
|
m1, _ := hex.DecodeString("0880f1969905128401f099b192f0abb1b9f3b280aff19e9aa2f3b89e84f484b39df1a7a6b0f1aea4b1f0adac94f3b39caaf1939281f1928a8af0abb1b0f0a8b3b3f3a88e94f2bd85acf29c97a9f2969da6f0b7a188f1908ea2f09a9c9bf19d86a6f29aada8f389bb95f0bf9d88f1a09d89f1b1a4b5f29b9eabf298a59df1b2a589f2979ebdf0b69880f18986b21a440a1508c7d8fb8897ca93d90910e8c4d8e8f2f8f0ccee010a1508afa8ffd8c085b393c50110e5bdedc3bddefe9b0b0a1408a1bedddba4cac5da3c10b8e5d9958ca7e3ec19225ae2f88cb2f8ffffffff018ceda99cfbffffffff01b9c298a407e295e8e9fcffffffff01f3b9ade5fcffffffff01c08bfea9fdffffffff01a2c2e5e1ffffffffff0186dcc5dafdffffffff01e9ffc7e507c9d89db8fdffffffff01")
|
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
|
|
|
if err := proto.Unmarshal(m1, &fdpu); err != nil {
|
2017-01-01 17:19:00 +00:00
|
|
|
t.Fatal("Unmarshalling message from v0.14.16:", err)
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
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
|
|
|
func testMarshal(t *testing.T, prefix string, m1, m2 proto.Message) bool {
|
|
|
|
buf, err := proto.Marshal(m1)
|
2014-09-22 19:42:11 +00:00
|
|
|
if err != nil {
|
|
|
|
t.Fatal(err)
|
|
|
|
}
|
|
|
|
|
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
|
|
|
err = proto.Unmarshal(buf, m2)
|
2014-09-22 19:42:11 +00:00
|
|
|
if err != nil {
|
|
|
|
t.Fatal(err)
|
|
|
|
}
|
|
|
|
|
2016-07-04 10:40:29 +00:00
|
|
|
bs1, _ := json.MarshalIndent(m1, "", " ")
|
|
|
|
bs2, _ := json.MarshalIndent(m2, "", " ")
|
|
|
|
if !bytes.Equal(bs1, bs2) {
|
2023-03-12 19:06:59 +00:00
|
|
|
os.WriteFile(prefix+"-1.txt", bs1, 0o644)
|
|
|
|
os.WriteFile(prefix+"-2.txt", bs2, 0o644)
|
2016-07-04 10:40:29 +00:00
|
|
|
return false
|
2014-09-22 19:42:11 +00:00
|
|
|
}
|
2016-01-12 11:12:06 +00:00
|
|
|
|
2016-07-04 10:40:29 +00:00
|
|
|
return true
|
2016-01-12 11:12:06 +00:00
|
|
|
}
|
2016-01-20 19:37:48 +00:00
|
|
|
|
2021-06-27 15:59:30 +00:00
|
|
|
func TestWriteCompressed(t *testing.T) {
|
|
|
|
for _, random := range []bool{false, true} {
|
|
|
|
buf := new(bytes.Buffer)
|
|
|
|
c := &rawConnection{
|
|
|
|
cr: &countingReader{Reader: buf},
|
|
|
|
cw: &countingWriter{Writer: buf},
|
|
|
|
compression: CompressionAlways,
|
|
|
|
}
|
|
|
|
|
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
|
|
|
msg := (&Response{Data: make([]byte, 10240)}).toWire()
|
2021-06-27 15:59:30 +00:00
|
|
|
if random {
|
|
|
|
// This should make the message uncompressible.
|
|
|
|
rand.Read(msg.Data)
|
|
|
|
}
|
|
|
|
|
|
|
|
if err := c.writeMessage(msg); err != nil {
|
|
|
|
t.Fatal(err)
|
|
|
|
}
|
|
|
|
got, err := c.readMessage(make([]byte, 4))
|
|
|
|
if err != nil {
|
|
|
|
t.Fatal(err)
|
|
|
|
}
|
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
|
|
|
if !bytes.Equal(got.(*bep.Response).Data, msg.Data) {
|
2021-06-27 15:59:30 +00:00
|
|
|
t.Error("received the wrong message")
|
|
|
|
}
|
|
|
|
|
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
|
|
|
hdr := &bep.Header{Type: typeOf(msg)}
|
|
|
|
size := int64(2 + proto.Size(hdr) + 4 + proto.Size(msg))
|
2023-02-07 11:07:34 +00:00
|
|
|
if c.cr.Tot() > size {
|
2021-06-27 15:59:30 +00:00
|
|
|
t.Errorf("compression enlarged message from %d to %d",
|
2023-02-07 11:07:34 +00:00
|
|
|
size, c.cr.Tot())
|
2021-06-27 15:59:30 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
2016-01-20 19:37:48 +00:00
|
|
|
|
2021-06-27 15:59:30 +00:00
|
|
|
func TestLZ4Compression(t *testing.T) {
|
2016-07-04 10:40:29 +00:00
|
|
|
for i := 0; i < 10; i++ {
|
|
|
|
dataLen := 150 + rand.Intn(150)
|
|
|
|
data := make([]byte, dataLen)
|
|
|
|
_, err := io.ReadFull(rand.Reader, data[100:])
|
|
|
|
if err != nil {
|
|
|
|
t.Fatal(err)
|
|
|
|
}
|
2021-06-27 15:59:30 +00:00
|
|
|
|
2022-01-17 17:52:43 +00:00
|
|
|
comp := make([]byte, lz4.CompressBlockBound(dataLen))
|
2021-06-27 15:59:30 +00:00
|
|
|
compLen, err := lz4Compress(data, comp)
|
2016-07-04 10:40:29 +00:00
|
|
|
if err != nil {
|
|
|
|
t.Errorf("compressing %d bytes: %v", dataLen, err)
|
|
|
|
continue
|
|
|
|
}
|
|
|
|
|
2021-06-27 15:59:30 +00:00
|
|
|
res, err := lz4Decompress(comp[:compLen])
|
2016-07-04 10:40:29 +00:00
|
|
|
if err != nil {
|
|
|
|
t.Errorf("decompressing %d bytes to %d: %v", len(comp), dataLen, err)
|
|
|
|
continue
|
|
|
|
}
|
|
|
|
if len(res) != len(data) {
|
|
|
|
t.Errorf("Incorrect len %d != expected %d", len(res), len(data))
|
|
|
|
}
|
|
|
|
if !bytes.Equal(data, res) {
|
|
|
|
t.Error("Incorrect decompressed data")
|
|
|
|
}
|
|
|
|
t.Logf("OK #%d, %d -> %d -> %d", i, dataLen, len(comp), dataLen)
|
2016-01-20 19:37:48 +00:00
|
|
|
}
|
|
|
|
}
|
2016-12-01 12:35:32 +00:00
|
|
|
|
2022-01-17 17:52:43 +00:00
|
|
|
func TestLZ4CompressionUpdate(t *testing.T) {
|
|
|
|
uncompressed := []byte("this is some arbitrary yet fairly compressible data")
|
|
|
|
|
|
|
|
// Compressed, as created by the LZ4 implementation in Syncthing 1.18.6 and earlier.
|
|
|
|
oldCompressed, _ := hex.DecodeString("00000033f0247468697320697320736f6d65206172626974726172792079657420666169726c7920636f6d707265737369626c652064617461")
|
|
|
|
|
|
|
|
// Verify that we can decompress
|
|
|
|
|
|
|
|
res, err := lz4Decompress(oldCompressed)
|
|
|
|
if err != nil {
|
|
|
|
t.Fatal(err)
|
|
|
|
}
|
|
|
|
if !bytes.Equal(uncompressed, res) {
|
|
|
|
t.Fatal("result does not match")
|
|
|
|
}
|
|
|
|
|
|
|
|
// Verify that our current compression is equivalent
|
|
|
|
|
|
|
|
buf := make([]byte, 128)
|
|
|
|
n, err := lz4Compress(uncompressed, buf)
|
|
|
|
if err != nil {
|
|
|
|
t.Fatal(err)
|
|
|
|
}
|
|
|
|
if !bytes.Equal(oldCompressed, buf[:n]) {
|
|
|
|
t.Logf("%x", oldCompressed)
|
|
|
|
t.Logf("%x", buf[:n])
|
|
|
|
t.Fatal("compression does not match")
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2016-12-01 12:35:32 +00:00
|
|
|
func TestCheckFilename(t *testing.T) {
|
|
|
|
cases := []struct {
|
|
|
|
name string
|
|
|
|
ok bool
|
|
|
|
}{
|
|
|
|
// Valid filenames
|
|
|
|
{"foo", true},
|
|
|
|
{"foo/bar/baz", true},
|
|
|
|
{"foo/bar:baz", true}, // colon is ok in general, will be filtered on windows
|
|
|
|
{`\`, true}, // path separator on the wire is forward slash, so as above
|
|
|
|
{`\.`, true},
|
|
|
|
{`\..`, true},
|
|
|
|
{".foo", true},
|
|
|
|
{"foo..", true},
|
|
|
|
|
|
|
|
// Invalid filenames
|
|
|
|
{"foo/..", false},
|
|
|
|
{"foo/../bar", false},
|
|
|
|
{"../foo/../bar", false},
|
|
|
|
{"", false},
|
|
|
|
{".", false},
|
|
|
|
{"..", false},
|
|
|
|
{"/", false},
|
|
|
|
{"/.", false},
|
|
|
|
{"/..", false},
|
|
|
|
{"/foo", false},
|
|
|
|
{"./foo", false},
|
|
|
|
{"foo./", false},
|
|
|
|
{"foo/.", false},
|
|
|
|
{"foo/", false},
|
|
|
|
}
|
|
|
|
|
|
|
|
for _, tc := range cases {
|
|
|
|
err := checkFilename(tc.name)
|
|
|
|
if (err == nil) != tc.ok {
|
|
|
|
t.Errorf("Unexpected result for checkFilename(%q): %v", tc.name, err)
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
2017-03-27 07:21:08 +00:00
|
|
|
|
|
|
|
func TestCheckConsistency(t *testing.T) {
|
|
|
|
cases := []struct {
|
|
|
|
fi FileInfo
|
|
|
|
ok bool
|
|
|
|
}{
|
|
|
|
{
|
|
|
|
// valid
|
|
|
|
fi: FileInfo{
|
|
|
|
Name: "foo",
|
|
|
|
Type: FileInfoTypeFile,
|
|
|
|
Blocks: []BlockInfo{{Size: 1234, Offset: 0, Hash: []byte{1, 2, 3, 4}}},
|
|
|
|
},
|
|
|
|
ok: true,
|
|
|
|
},
|
|
|
|
{
|
|
|
|
// deleted with blocks
|
|
|
|
fi: FileInfo{
|
|
|
|
Name: "foo",
|
|
|
|
Deleted: true,
|
|
|
|
Type: FileInfoTypeFile,
|
|
|
|
Blocks: []BlockInfo{{Size: 1234, Offset: 0, Hash: []byte{1, 2, 3, 4}}},
|
|
|
|
},
|
|
|
|
ok: false,
|
|
|
|
},
|
|
|
|
{
|
|
|
|
// no blocks
|
|
|
|
fi: FileInfo{
|
|
|
|
Name: "foo",
|
|
|
|
Type: FileInfoTypeFile,
|
|
|
|
},
|
|
|
|
ok: false,
|
|
|
|
},
|
|
|
|
{
|
|
|
|
// directory with blocks
|
|
|
|
fi: FileInfo{
|
|
|
|
Name: "foo",
|
|
|
|
Type: FileInfoTypeDirectory,
|
|
|
|
Blocks: []BlockInfo{{Size: 1234, Offset: 0, Hash: []byte{1, 2, 3, 4}}},
|
|
|
|
},
|
|
|
|
ok: false,
|
|
|
|
},
|
|
|
|
}
|
|
|
|
|
|
|
|
for _, tc := range cases {
|
|
|
|
err := checkFileInfoConsistency(tc.fi)
|
|
|
|
if tc.ok && err != nil {
|
|
|
|
t.Errorf("Unexpected error %v (want nil) for %v", err, tc.fi)
|
|
|
|
}
|
|
|
|
if !tc.ok && err == nil {
|
|
|
|
t.Errorf("Unexpected nil error for %v", tc.fi)
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
2018-04-16 18:08:50 +00:00
|
|
|
|
|
|
|
func TestBlockSize(t *testing.T) {
|
|
|
|
cases := []struct {
|
|
|
|
fileSize int64
|
|
|
|
blockSize int
|
|
|
|
}{
|
|
|
|
{1 << KiB, 128 << KiB},
|
|
|
|
{1 << MiB, 128 << KiB},
|
|
|
|
{499 << MiB, 256 << KiB},
|
|
|
|
{500 << MiB, 512 << KiB},
|
|
|
|
{501 << MiB, 512 << KiB},
|
|
|
|
{1 << GiB, 1 << MiB},
|
|
|
|
{2 << GiB, 2 << MiB},
|
|
|
|
{3 << GiB, 2 << MiB},
|
|
|
|
{500 << GiB, 16 << MiB},
|
|
|
|
{50000 << GiB, 16 << MiB},
|
|
|
|
}
|
|
|
|
|
|
|
|
for _, tc := range cases {
|
|
|
|
size := BlockSize(tc.fileSize)
|
|
|
|
if size != tc.blockSize {
|
|
|
|
t.Errorf("BlockSize(%d), size=%d, expected %d", tc.fileSize, size, tc.blockSize)
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
var blockSize int
|
|
|
|
|
|
|
|
func BenchmarkBlockSize(b *testing.B) {
|
|
|
|
for i := 0; i < b.N; i++ {
|
|
|
|
blockSize = BlockSize(16 << 30)
|
|
|
|
}
|
|
|
|
}
|
2018-06-08 10:02:16 +00:00
|
|
|
|
2019-05-29 10:14:00 +00:00
|
|
|
// TestClusterConfigAfterClose checks that ClusterConfig does not deadlock when
|
|
|
|
// ClusterConfig is called on a closed connection.
|
|
|
|
func TestClusterConfigAfterClose(t *testing.T) {
|
|
|
|
m := newTestModel()
|
|
|
|
|
2023-08-21 17:44:33 +00:00
|
|
|
rw := testutil.NewBlockingRW()
|
|
|
|
c := getRawConnection(NewConnection(c0ID, rw, rw, testutil.NoopCloser{}, m, new(mockedConnectionInfo), CompressionAlways, nil, testKeyGen))
|
2019-05-29 10:14:00 +00:00
|
|
|
c.Start()
|
2020-11-27 10:31:20 +00:00
|
|
|
defer closeAndWait(c, rw)
|
2019-05-29 10:14:00 +00:00
|
|
|
|
|
|
|
c.internalClose(errManual)
|
|
|
|
|
|
|
|
done := make(chan struct{})
|
|
|
|
go func() {
|
2024-08-24 10:45:10 +00:00
|
|
|
c.ClusterConfig(&ClusterConfig{})
|
2019-05-29 10:14:00 +00:00
|
|
|
close(done)
|
|
|
|
}()
|
|
|
|
|
|
|
|
select {
|
|
|
|
case <-done:
|
|
|
|
case <-time.After(time.Second):
|
|
|
|
t.Fatal("timed out before Cluster Config returned")
|
|
|
|
}
|
|
|
|
}
|
2019-06-14 17:04:41 +00:00
|
|
|
|
|
|
|
func TestDispatcherToCloseDeadlock(t *testing.T) {
|
|
|
|
// Verify that we don't deadlock when calling Close() from within one of
|
|
|
|
// the model callbacks (ClusterConfig).
|
|
|
|
m := newTestModel()
|
2023-08-21 17:44:33 +00:00
|
|
|
rw := testutil.NewBlockingRW()
|
|
|
|
c := getRawConnection(NewConnection(c0ID, rw, &testutil.NoopRW{}, testutil.NoopCloser{}, m, new(mockedConnectionInfo), CompressionAlways, nil, testKeyGen))
|
lib/protocol: Refactor interface (#9375)
This is a refactor of the protocol/model interface to take the actual
message as the parameter, instead of the broken-out fields:
```diff
type Model interface {
// An index was received from the peer device
- Index(conn Connection, folder string, files []FileInfo) error
+ Index(conn Connection, idx *Index) error
// An index update was received from the peer device
- IndexUpdate(conn Connection, folder string, files []FileInfo) error
+ IndexUpdate(conn Connection, idxUp *IndexUpdate) error
// A request was made by the peer device
- Request(conn Connection, folder, name string, blockNo, size int32, offset int64, hash []byte, weakHash uint32, fromTemporary bool) (RequestResponse, error)
+ Request(conn Connection, req *Request) (RequestResponse, error)
// A cluster configuration message was received
- ClusterConfig(conn Connection, config ClusterConfig) error
+ ClusterConfig(conn Connection, config *ClusterConfig) error
// The peer device closed the connection or an error occurred
Closed(conn Connection, err error)
// The peer device sent progress updates for the files it is currently downloading
- DownloadProgress(conn Connection, folder string, updates []FileDownloadProgressUpdate) error
+ DownloadProgress(conn Connection, p *DownloadProgress) error
}
```
(and changing the `ClusterConfig` to `*ClusterConfig` for symmetry;
we'll be forced to use all pointers everywhere at some point anyway...)
The reason for this is that I have another thing cooking which is a
small troubleshooting change to check index consistency during transfer.
This required adding a field or two to the index/indexupdate messages,
and plumbing the extra parameters in umpteen changes is almost as big a
diff as this is. I figured let's do it once and avoid having to do that
in the future again...
The rest of the diff falls out of the change above, much of it being in
test code where we run these methods manually...
2024-01-31 07:18:27 +00:00
|
|
|
m.ccFn = func(*ClusterConfig) {
|
2019-06-14 17:04:41 +00:00
|
|
|
c.Close(errManual)
|
|
|
|
}
|
|
|
|
c.Start()
|
2020-11-27 10:31:20 +00:00
|
|
|
defer closeAndWait(c, rw)
|
2019-06-14 17:04:41 +00:00
|
|
|
|
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
|
|
|
c.inbox <- &bep.ClusterConfig{}
|
2019-06-14 17:04:41 +00:00
|
|
|
|
|
|
|
select {
|
|
|
|
case <-c.dispatcherLoopStopped:
|
|
|
|
case <-time.After(time.Second):
|
|
|
|
t.Fatal("timed out before dispatcher loop terminated")
|
|
|
|
}
|
|
|
|
}
|
2020-03-10 13:46:49 +00:00
|
|
|
|
2020-03-17 06:40:52 +00:00
|
|
|
func TestIndexIDString(t *testing.T) {
|
|
|
|
// Index ID is a 64 bit, zero padded hex integer.
|
|
|
|
var i IndexID = 42
|
|
|
|
if i.String() != "0x000000000000002A" {
|
|
|
|
t.Error(i.String())
|
|
|
|
}
|
|
|
|
}
|
2020-11-27 10:31:20 +00:00
|
|
|
|
2021-03-22 20:50:19 +00:00
|
|
|
func closeAndWait(c interface{}, closers ...io.Closer) {
|
2020-11-27 10:31:20 +00:00
|
|
|
for _, closer := range closers {
|
|
|
|
closer.Close()
|
|
|
|
}
|
|
|
|
var raw *rawConnection
|
|
|
|
switch i := c.(type) {
|
|
|
|
case *rawConnection:
|
|
|
|
raw = i
|
2021-03-22 20:50:19 +00:00
|
|
|
default:
|
|
|
|
raw = getRawConnection(c.(Connection))
|
2020-11-27 10:31:20 +00:00
|
|
|
}
|
|
|
|
raw.internalClose(ErrClosed)
|
|
|
|
raw.loopWG.Wait()
|
|
|
|
}
|
2021-03-22 20:50:19 +00:00
|
|
|
|
|
|
|
func getRawConnection(c Connection) *rawConnection {
|
|
|
|
var raw *rawConnection
|
|
|
|
switch i := c.(type) {
|
|
|
|
case wireFormatConnection:
|
|
|
|
raw = i.Connection.(encryptedConnection).conn
|
|
|
|
case encryptedConnection:
|
|
|
|
raw = i.conn
|
|
|
|
}
|
|
|
|
return raw
|
|
|
|
}
|