Go to file
Henry de Valence adc421f7fe Implement ZcashDeserialize for Message::Version.
This has a test that the serialization implementation round trips
correctly, but is very much a work in progress.  Issues with this code
include:

The deserialization logic for message headers is somewhat ugly because
of a lack of a convenient idiom for reading a few bytes at a time into a
fixed-size array.  Perhaps this could be fixed with an extension trait,
or avoided altogether by using `u32`s instead of `[u8; 4]`, even when
the latter is the "morally correct type".

Deserialization does an extra allocation, copying the body into a
temporary buffer.  This avoids two problems: 1) capping the number of
bytes that can be read by the `Read`er passed into the body parser and
2) allows making two passes over the body data, one to parse it and one
to compute the checksum.

We could avoid making two passes over the body by computing the checksum
simultaneously with the parsing. A convenient way to do this would be to
define a

```
struct ChecksumReader<R: Read> {
    inner: R,
    digest: Sha256,
}

impl<R: Read> Read for ChecksumReader<R> { /* ... */ }
```

and implement `Read` for `ChecksumReader` to forward reads from the
inner reader, copying data into the digest object as it does so.  (It
could also have a maximum length to enforce that we do not read past the
nominal end of the body).

A similar `ChecksumWriter` could be used during serialization, although
because the checksum is at the beginning rather than the end of the
message it does not help avoid an allocation there.  It could also be
generic over a `Digest` implementation, although because we need a
truncated double-SHA256 we would have to write a custom `Digest`
implementation, so this is probably not worthwhile unless we have other
checksum types.

Finally, this does very minimal testing -- just round-trip serialization
on a single message.  It would be good to build in support for
property-based testing, probably using `proptest`; if we could define
generation and shrinking strategies for every component type of every
message, we could do strong randomized testing of the serialization.
2019-09-18 17:32:06 -04:00
.github/workflows Continuous integration (#2) 2019-09-05 13:08:48 -04:00
zebra-chain Add missing derives to newtypes. 2019-09-18 17:32:06 -04:00
zebra-client Create workspace skeleton based on design.md 2019-08-29 14:46:54 -07:00
zebra-consensus Create workspace skeleton based on design.md 2019-08-29 14:46:54 -07:00
zebra-network Implement ZcashDeserialize for Message::Version. 2019-09-18 17:32:06 -04:00
zebra-reactor Create workspace skeleton based on design.md 2019-08-29 14:46:54 -07:00
zebra-rpc Create workspace skeleton based on design.md 2019-08-29 14:46:54 -07:00
zebra-script Create workspace skeleton based on design.md 2019-08-29 14:46:54 -07:00
zebra-storage Create workspace skeleton based on design.md 2019-08-29 14:46:54 -07:00
zebrad Tracing endpoint (#3) 2019-09-09 13:05:42 -07:00
.gitignore Create workspace skeleton based on design.md 2019-08-29 14:46:54 -07:00
.rustfmt.toml Tracing endpoint (#3) 2019-09-09 13:05:42 -07:00
Cargo.toml Create workspace skeleton based on design.md 2019-08-29 14:46:54 -07:00
Dockerfile Continuous integration (#2) 2019-09-05 13:08:48 -04:00
cloudbuild.yaml Continuous integration (#2) 2019-09-05 13:08:48 -04:00
rust-toolchain Tracing endpoint (#3) 2019-09-09 13:05:42 -07:00