zecfoundation
/
zebra
mirror of https://github.com/ZcashFoundation/zebra.git
1
0
Fork 0
Code Issues Projects Releases Wiki Activity
zebra/zebra-network/Cargo.toml

41 lines
1.2 KiB
TOML
Raw Normal View History

Create workspace skeleton based on design.md
2019-08-29 14:46:54 -07:00
[package]
name = "zebra-network"
Align crate versions and user-agent with NU numbers. We had a brief discussion on discord and it seemed like we had consensus on the following versioning policy: * zebrad: match major version to NU version, so we will start by releasing zebrad 3.0.0; * zebra-* libraries: start by matching zebrad's version, then increment major versions of each library as we need to make breaking changes (potentially faster than the zebrad version, always respecting semver but making no guarantees about the longevity of major releases). This commit sets all of the crate versions to 3.0.0-alpha.0 -- the -alpha.0 marks it as a prerelease not subject to perfect adherence to compatibility guarantees.
2020-07-24 11:12:23 -07:00
version = "3.0.0-alpha.0"
Fix authorship, license information. (#55) * Fix authorship, license information. I *thought* I had done a sed pass over the Cargo defaults when doing repository initialization, but I guess I missed it or something. Anyways, fixed now.
2019-10-08 09:25:59 -07:00
authors = ["Zcash Foundation <zebra@zfnd.org>"]
license = "MIT OR Apache-2.0"
Create workspace skeleton based on design.md
2019-08-29 14:46:54 -07:00
edition = "2018"
# See more keys and their definitions at https://doc.rust-lang.org/cargo/reference/manifest.html
[dependencies]
Replace PeerServices(u64) with a bitflags struct. This gives considerably better ergonomics.
2019-09-30 11:58:32 -07:00
bitflags = "1.2"
Try writing message headers.
2019-09-13 05:29:17 -07:00
byteorder = "1.3"
deps: move to tokio 0.3, tower 0.4 This change is mostly mechanical, with the exception of the changes to the `tower-batch` middleware. This middleware was adapted from `tower::buffer`, and the `tower::buffer` code was changed to implement its own bounded queue, because Tokio 0.3 removed the `mpsc::Sender::poll_send` method. See https://github.com/tower-rs/tower/commit/ddc64e8d4d4d499adef569e284f317288edd6513 for more context on the Tower changes. To match Tower as closely as possible in order to be able to upstream `tower-batch`, those changes are copied from `tower::Buffer` to `tower-batch`.
2020-11-19 11:54:20 -08:00
bytes = "0.6"
Replace Timestamp with chrono::DateTime<Utc>
2019-09-11 19:24:16 -07:00
chrono = "0.4"
Implement custom Debug for Magic types Related to #63
2019-10-15 16:38:44 -07:00
hex = "0.4"
# indexmap has rayon support for parallel iteration,
Beginning of peerset implementation. (#62) * Don't expose submodules of zebra_network::peer. * PeerSet, PeerDiscover stubs. Co-authored-by: Deirdre Connolly <deirdre@zfnd.org> * Initial work on PeerSet. This is adapted from the MIT-licensed tower-balance implementation. * Use PeerSet in the connect stub.
2019-10-10 18:15:24 -07:00
# which we don't use, so disable it to drop the dependencies.
build(deps): bump indexmap from 1.5.2 to 1.6.0 Bumps [indexmap](https://github.com/bluss/indexmap) from 1.5.2 to 1.6.0. - [Release notes](https://github.com/bluss/indexmap/releases) - [Commits](https://github.com/bluss/indexmap/compare/1.5.2...1.6.0) Signed-off-by: dependabot[bot] <support@github.com>
2020-09-07 02:01:15 -07:00
indexmap = { version = "1.6", default-features = false }
Implement custom Debug for Magic types Related to #63
2019-10-15 16:38:44 -07:00
pin-project = "0.4"
rand = "0.7"
serde = { version = "1", features = ["serde_derive"] }
Fix merge artifacts in Cargo.toml
2019-10-16 22:56:25 -07:00
thiserror = "1"
Move all git dependencies to published crates. (#58) The earlier issues with version resolution incompatibilities are now resolved, and all the upstream changes we made to tracing are released.
2019-10-08 21:10:01 -07:00
feature: Use the Heartwood protocol version in zebra-network
2020-07-21 01:41:18 -07:00
futures = "0.3"
Downgrade tokio to 0.3.4 to avoid a time wheel panic (#1453) See tokio-rs/tokio#2789 for details. We were seeing this panic during normal operation, not just at shutdown.
2020-12-03 19:52:37 -08:00
tokio = { version = "0.3.4", features = ["net", "time", "stream", "tracing", "macros", "rt-multi-thread"] }
deps: move to tokio 0.3, tower 0.4 This change is mostly mechanical, with the exception of the changes to the `tower-batch` middleware. This middleware was adapted from `tower::buffer`, and the `tower::buffer` code was changed to implement its own bounded queue, because Tokio 0.3 removed the `mpsc::Sender::poll_send` method. See https://github.com/tower-rs/tower/commit/ddc64e8d4d4d499adef569e284f317288edd6513 for more context on the Tower changes. To match Tower as closely as possible in order to be able to upstream `tower-batch`, those changes are copied from `tower::Buffer` to `tower-batch`.
2020-11-19 11:54:20 -08:00
tokio-util = { version = "0.5", features = ["codec"] }
tower = { version = "0.4", features = ["retry", "discover", "load", "load-shed", "timeout", "util", "buffer"] }
Initial tower-based peer implementation. (#17) Add a tower-based peer implementation. Tower provides middleware for request-response oriented protocols, while Bitcoin/Zcash just send messages which could be interpreted either as requests or responses, depending on context. To bridge this mismatch we define our own internal request/response protocol, and implement a per-peer event loop that scans incoming messages and interprets them either as requests from the remote peer to our node, or as responses to requests we made previously. This is performed by the `PeerService` task, and a corresponding `PeerClient: tower::Service` can send it requests. These tasks are themselves created by a `PeerConnector: tower::Service` which dials a remote peer and performs a handshake.
2019-10-07 15:36:16 -07:00
Metrics MVP: add two metrics and export them to Prometheus. Co-authored-by: Deirdre Connolly <deirdre@zfnd.org>
2020-02-14 13:38:33 -08:00
metrics = "0.12"
feature: Use the Heartwood protocol version in zebra-network
2020-07-21 01:41:18 -07:00
tracing = "0.1"
tracing-futures = "0.2"
tracing-error = { version = "0.1.2", features = ["traced-error"] }
Metrics MVP: add two metrics and export them to Prometheus. Co-authored-by: Deirdre Connolly <deirdre@zfnd.org>
2020-02-14 13:38:33 -08:00
Initial tower-based peer implementation. (#17) Add a tower-based peer implementation. Tower provides middleware for request-response oriented protocols, while Bitcoin/Zcash just send messages which could be interpreted either as requests or responses, depending on context. To bridge this mismatch we define our own internal request/response protocol, and implement a per-peer event loop that scans incoming messages and interprets them either as requests from the remote peer to our node, or as responses to requests we made previously. This is performed by the `PeerService` task, and a corresponding `PeerClient: tower::Service` can send it requests. These tasks are themselves created by a `PeerConnector: tower::Service` which dials a remote peer and performs a handshake.
2019-10-07 15:36:16 -07:00
zebra-chain = { path = "../zebra-chain" }
feature: Use the Heartwood protocol version in zebra-network
2020-07-21 01:41:18 -07:00
[dev-dependencies]
proptest = "0.10"
proptest-derive = "0.2.0"
Limit protocol messages size (#645) * change body msg limit and test case * accept body at the exact limit len * test the edges of the limit value
2020-07-15 02:15:52 -07:00
zebra-test = { path = "../zebra-test/" }