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

26 lines
806 B
TOML
Raw Normal View History

Create workspace skeleton based on design.md
2019-08-29 14:46:54 -07:00
[package]
name = "zebra-network"
version = "0.1.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"
Refactor message serialization as a tokio codec. This provides a significantly cleaner API to consumers, because it allows using adaptors that convert a TCP stream to a stream of messages, and potentially allows more efficient message handling.
2019-09-24 11:25:06 -07:00
bytes = "0.4"
Use rand::thread_rng to impl Default for Nonce.
2019-09-19 14:13:38 -07:00
rand = "0.7"
Try writing message headers.
2019-09-13 05:29:17 -07:00
byteorder = "1.3"
Replace Timestamp with chrono::DateTime<Utc>
2019-09-11 19:24:16 -07:00
chrono = "0.4"
Try writing message headers.
2019-09-13 05:29:17 -07:00
failure = "0.1"
Add a `Config` struct to zebra-network. This struct is pulled into the main abscissa config as a subsection.
2019-10-08 13:57:24 -07:00
serde = { version = "1", features = ["serde_derive"] }
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
tokio = "=0.2.0-alpha.6"
tower = { git = "https://github.com/tower-rs/tower", branch = "v0.3.x" }
Use tracing::instrument and monitor for messages.
2019-09-23 18:11:05 -07:00
tracing = { git = "https://github.com/tokio-rs/tracing" }
tracing-futures = { git = "https://github.com/tokio-rs/tracing", features = ["tokio-alpha"], default-features = false }
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
futures-preview = { version = "=0.3.0-alpha.19", features = ["async-await"] }
Change Message serialization to async send/recv. Because we want to be able to read messages from async sources (like a tcp socket), we need to have at least async header parsing logic, so that we can correctly determine how many bytes to await to parse each message, so it makes sense for the entire message parsing functions to be async. Because we perform message serialization into async readers and writers in the context of sending messages over the network, code using these functions is more clear with these names.
2019-09-19 10:08:35 -07: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" }