pub struct Config {
pub appname: String,
pub key: SigningKey,
pub releases: PathBuf,
pub stream_threshold: u64,
pub stream_buffer: usize,
pub read_buffer: usize,
pub versions: HashMap<Version, Sha256Hash>,
}
Expand description
The configuration options for the server.
Most configuration options should be fairly self-explanatory, according to their individual documentation. However, there are some areas that merit further commentary, given in the following sections.
§Release file naming conventions
Notably, the filename format for the binary release files is expected to be
appname-version
, where appname
is the name of the application, and
version
is the version number. This is used to match against the files in
the releases
directory, to ensure that the correct files
are served. The version number is expected to be in the format x.y.z
,
where x
, y
, and z
are the major, minor, and patch version numbers
respectively, following the Semantic Versioning
specification.
At present, file extensions are not supported, as initial support is for Linux only. The release files are expected to be straightforward binaries, with no additional packaging or compression. Additionally, only one architecture is supported at present, which is undetermined and up to the implementer to decide. All releases are expected to be stable, and there is no way to specify a release as a beta.
§Release file streaming
If the release files are larger than a (configurable) size they will be streamed to the client, rather than read into memory all at once. This is to ensure that the server can handle large files without running out of memory.
Note that the sizes of the stream buffer and read buffer are hugely important to performance, with smaller buffers greatly impacting download speeds. The recommended default values have been carefully chosen based on extensive testing, and should not generally need to be changed. However, on a system with lots of users and very few large files it may be worth decreasing the buffer sizes to reduce memory usage when those files are requested, and on a system with very few users and lots of large files it may be worth increasing the buffer sizes to improve throughput. However, the chosen values are already within 5-10% of the very best possible speeds, so any increase should be made with caution. It is more likely that they would need to be decreased a little on a very busy system with a lot of large files, where the memory usage could become a problem and the raw speed of each download becomes a secondary concern.
Fields§
§appname: String
The name of the application. This is used to match against the files in
the releases
directory, to ensure that the correct
files are served.
key: SigningKey
The private key for the server. This is used to sign the HTTP responses to ensure that they have not been tampered with. The format used is Ed25519, which is a modern and secure algorithm.
releases: PathBuf
The path to the directory containing the binary release files. This
should follow a flat structure, with the files named according to the
appname
and version number.
stream_threshold: u64
The file size at which to start streaming, in KB. Below this size, the
file will be read into memory and served all at once. A sensible default
is 1000
(1MB).
stream_buffer: usize
The size of the stream buffer to use when streaming files, in KB. A
sensible default is 256
(256KB).
read_buffer: usize
The size of the read buffer to use when streaming files, in KB. A
sensible default is 128
(128KB).
versions: HashMap<Version, Sha256Hash>
The available versions of the application. This is a map of SemVer version numbers against the SHA256 hashes of the binary release files. The hashes are required so that the server can verify the integrity of the files before serving them to clients.