Handshake #125
Handshake #125
Conversation
| false, | ||
| ); | ||
|
|
||
| let domain = format!("0x{}", hex::encode(vec![0x0, 0x0, 0x5, 0x2])); |
There was a problem hiding this comment.
| task_executor = { workspace = true } | ||
| tokio = { workspace = true } | ||
| tracing = { workspace = true } | ||
| types = { workspace = true } | ||
| version = { workspace = true } | ||
| serde_json = "1.0.137" | ||
| thiserror = "1.0.69" | ||
| prost = "0.13.4" |
There was a problem hiding this comment.
we use quick-protobuf in libp2p which is also available in the dependency chain, so you shouldn't need to depend on prost which is also helpful as you don't need to specifiy prost-build in the build dependencies
anchor/network/src/behaviour.rs
Outdated
| } | ||
|
|
||
| #[derive(Default)] | ||
| struct DummyPeerInfoStore {} |
There was a problem hiding this comment.
this and the PeerInfoStore trait are not required right? As I see them commented in the HandshakeBehaviour impl
|
|
||
| /// Event emitted on handshake completion or failure. | ||
| #[derive(Debug)] | ||
| pub enum HandshakeEvent { |
There was a problem hiding this comment.
nit:
| pub enum HandshakeEvent { | |
| pub enum Event { |
the module already gives out the namespace, no need for redundancy
| } | ||
|
|
||
| /// Network behaviour handling the handshake protocol. | ||
| pub struct HandshakeBehaviour { |
There was a problem hiding this comment.
nit:
| pub struct HandshakeBehaviour { | |
| pub struct Behaviour { |
| /// Request-response behaviour for the handshake protocol. | ||
| behaviour: Behaviour<EnvelopeCodec>, | ||
| /// Pending outgoing handshake requests. | ||
| pending_handshakes: HashMap<OutboundRequestId, PeerId>, |
There was a problem hiding this comment.
do we need to keep track of the established connections which haven't completed the handshake yet?
There was a problem hiding this comment.
I'm not sure yet. The idea was to know if a response is for a previous request.
There was a problem hiding this comment.
Removed as this is already handled by libp2p
| } | ||
|
|
||
| /// Network behaviour handling the handshake protocol. | ||
| pub struct HandshakeBehaviour { |
There was a problem hiding this comment.
skimming through the NetworkBehaviour implementation, and without knowing much about the requirements I wonder if we can suffice our needs by just implementing the Codec trait and not needing to have request-response as a sub behaviour
There was a problem hiding this comment.
What would this approach look like?
There was a problem hiding this comment.
using the request-response Behaviour and then doing the validation envelope signing validation logic in the Codec implementation.
Does that make sense Diego?
There was a problem hiding this comment.
Yes, having the validation in the codec is the way to go. About only one behavior, I'll need to think more about it.
| use thiserror::Error; | ||
|
|
||
| #[derive(Error, Debug)] | ||
| pub enum HandshakeError { |
There was a problem hiding this comment.
nit:
| pub enum HandshakeError { | |
| pub enum Error { |
| use thiserror::Error; | ||
|
|
||
| #[derive(Error, Debug)] | ||
| pub enum HandshakeError { |
There was a problem hiding this comment.
do we need thiserror::Error for our Errors?
We are probably fine having an Enum and impl'ing Display and Error for it like request_response::OutboundFailure does it for example.
Nonetheless since it's probably already in the dependency chain feel free to ignore this
There was a problem hiding this comment.
This needs to be revisited, but It'll probably be removed.
There was a problem hiding this comment.
Another advantage is the #[from] see dc79ba7
|
|
||
| /// A `Codec` that reads/writes an **`Envelope`** | ||
| #[derive(Clone, Debug, Default)] | ||
| pub struct EnvelopeCodec; |
There was a problem hiding this comment.
nit:
| pub struct EnvelopeCodec; | |
| pub struct Codec; |
| /// - Provide a domain (for signing separation) | ||
| /// - Provide a "codec" (payload type) | ||
| /// - Marshal to bytes, unmarshal from bytes | ||
| pub trait Record { |
There was a problem hiding this comment.
this seems necessary right? As we are only using NodeInfo
diegomrsantos
force-pushed
the
handshake
branch
2 times, most recently
from
a383724 to
9e8c770
Compare
diegomrsantos
force-pushed
the
handshake
branch
from
9e8c770 to
30d58d3
Compare
diegomrsantos
force-pushed
the
handshake
branch
from
e1a5276 to
ff0c250
Compare
diegomrsantos
force-pushed
the
handshake
branch
from
fdd1b40 to
949101a
Compare
Issue Addressed
Which issue # does this PR address?
Proposed Changes
Please list or describe the changes introduced by this PR.
Additional Info
Please provide any additional information. For example, future considerations
or information useful for reviewers.