e52be3d83e
So there were some issues here. The main problem was that model.Close(deviceID) was overloaded to mean "the connection was closed by the protocol layer" and "i want to close this connection". That meant it could get called twice - once *to* close the connection and then once more when the connection *was* closed. After this refactor there is instead a Closed(conn) method that is the callback. I didn't need to change the parameter in the end, but I think it's clearer what it means when it takes the connection that was closed instead of a device ID. To close a connection, the new close(deviceID) method is used instead, which only closes the underlying connection and leaves the cleanup to the Closed() callback. I also changed how we do connection switching. Instead of the connection service calling close and then adding the connection, it just adds the new connection. The model knows that it already has a connection and makes sure to close and clean out that one before adding the new connection. To make sure to sequence this properly I added a new map of channels that get created on connection add and closed by Closed(), so that AddConnection() can do the close and wait for the cleanup to happen before proceeding. GitHub-Pull-Request: https://github.com/syncthing/syncthing/pull/3490 |
||
|---|---|---|
| assets | ||
| cmd | ||
| debtpl | ||
| etc | ||
| gui | ||
| lib | ||
| man | ||
| script | ||
| test | ||
| vendor | ||
| .gitattributes | ||
| .gitignore | ||
| .mailmap | ||
| AUTHORS | ||
| build.go | ||
| build.sh | ||
| CONDUCT.md | ||
| CONTRIBUTING.md | ||
| ISSUE_TEMPLATE.md | ||
| LICENSE | ||
| NICKS | ||
| PULL_REQUEST_TEMPLATE.md | ||
| README.md | ||
Syncthing
This is the Syncthing project which pursues the following goals:
-
Define a protocol for synchronization of a folder between a number of collaborating devices. This protocol should be well defined, unambiguous, easily understood, free to use, efficient, secure and language neutral. This is called the Block Exchange Protocol.
-
Provide the reference implementation to demonstrate the usability of said protocol. This is the
syncthingutility. We hope that alternative, compatible implementations of the protocol will arise.
The two are evolving together; the protocol is not to be considered stable until Syncthing 1.0 is released, at which point it is locked down for incompatible changes.
Getting Started
Take a look at the getting started guide.
There are a few examples for keeping Syncthing running in the background on your system in the etc directory. There are also several GUI implementations for Windows, Mac and Linux.
Vote on features/bugs
We'd like to encourage you to vote on issues that matter to you. This helps the team understand what are the biggest pain points for our users, and could potentially influence what is being worked on next.
Getting in Touch
The first and best point of contact is the Forum. There is also an IRC
channel, #syncthing on freenode (with a web client), for talking
directly to developers and users. If you've found something that is clearly a
bug, feel free to report it in the GitHub issue tracker.
Building
Building Syncthing from source is easy, and there's a guide that describes it for both Unix and Windows systems.
Signed Releases
As of v0.10.15 and onwards release binaries are GPG signed with the key D26E6ED000654A3E, available from https://syncthing.net/security.html and most key servers.
There is also a built in automatic upgrade mechanism (disabled in some distribution channels) which uses a compiled in ECDSA signature. Mac OS X binaries are also properly code signed.
Documentation
Please see the Syncthing documentation site.
All code is licensed under the MPLv2 License.