perso/syncthing-arm
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity

vendor: Update github.com/xtaci/kcp

Browse Source
This commit is contained in:
Jakob Borg
2017-03-07 14:28:09 +01:00
parent 81af29e3e2
commit b3e2665a79
34 changed files with 686 additions and 3335 deletions
Download Patch File Download Diff File Expand all files Collapse all files

45
vendor/github.com/klauspost/reedsolomon/examples/README.md generated vendored
View File

@@ -1,45 +0,0 @@
# Examples
This folder contains usage examples of the Reed-Solomon encoder.
# Simple Encoder/Decoder
Shows basic use of the encoder, and will encode a single file into a number of
data and parity shards. This is meant as an example and is not meant for production use
since there is a number of shotcomings noted below.
To build an executable use:
```bash
go build simple-decoder.go
go build simple-encoder.go
```
# Streamin API examples
There are streaming examples of the same functionality, which streams data instead of keeping it in memory.
To build the executables use:
```bash
go build stream-decoder.go
go build stream-encoder.go
```
## Shortcomings
* If the file size of the input isn't diviable by the number of data shards
the output will contain extra zeroes
* If the shard numbers isn't the same for the decoder as in the
encoder, invalid output will be generated.
* If values have changed in a shard, it cannot be reconstructed.
* If two shards have been swapped, reconstruction will always fail.
You need to supply the shards in the same order as they were given to you.
The solution for this is to save a metadata file containing:
* File size.
* The number of data/parity shards.
* HASH of each shard.
* Order of the shards.
If you save these properties, you should abe able to detect file corruption in a shard and be able to reconstruct your data if you have the needed number of shards left.