Eth2.0-specs: Clarification on the initiating client of `Hello`
Just want to confirm: I'm not sure who should open a new stream Hello to another upon connection. It should be great to clarify this. Should both sides do it, or just the client who initiates the connection opens the stream?
mhchia
All 3 comments
My understanding:
To begin, I discover a peer's identity and location yielding a multiaddr with this information (something like ip/IPV4_ADDR/tcp/PORT/p2p/PEER_ID). I inject this info to the peer store and then ask my libp2p implementation to dial this peer. There is a handshake that is transparent to me (AIUI) that upgrades the connection to one providing security and multiplexing guarantees at the transport level. I, as the initiator, now MUST open a new stream under the /eth2/beacon_chain/req/hello/1/ protocol and send the only valid message here, Hello. I close my end of the connection and wait for the remote peer's response.
The peer I connected to will see this incoming message from me and then MUST send its own Hello in response. The remote peer closes its end of the connection after sending the response Hello. At this point, each side can decide what to do following the spec (aka the peer missing data should start syncing the chain or incompatible peers are disconnected).
Does this clarify the initial handshake?
ralexstokes
on 13 Aug 2019
@ralexstokes Thank you for the clarification.
I, as the initiator, now MUST open a new stream under the /eth2/beacon_chain/req/hello/1/ protocol and send the only valid message here, Hello. I close my end of the connection and wait for the remote peer's response.
Yeah this is just what I want to confirm: who should open the stream Hello. If we all agree that the connection initiator should open the stream, probably we can specify it in the spec?
mhchia
on 13 Aug 2019
I think this is clarified in the updates made in v08x -- https://github.com/ethereum/eth2.0-specs/blob/v08x/specs/networking/p2p-interface.md#status
The dialing client MUST send a Status request upon connection.
djrtwo
on 17 Sep 2019
Related issues
paulhauner
路
4Comments
ralexstokes
路
3Comments
mratsim
路
4Comments
jamesray1
路
4Comments
djrtwo
路
3Comments
Most helpful comment
My understanding:
To begin, I discover a peer's identity and location yielding a multiaddr with this information (something like
ip/IPV4_ADDR/tcp/PORT/p2p/PEER_ID). I inject this info to the peer store and then ask mylibp2pimplementation to dial this peer. There is a handshake that is transparent to me (AIUI) that upgrades the connection to one providing security and multiplexing guarantees at the transport level. I, as the initiator, now MUST open a new stream under the/eth2/beacon_chain/req/hello/1/protocol and send the only valid message here,Hello. I close my end of the connection and wait for the remote peer's response.The peer I connected to will see this incoming message from me and then MUST send its own
Helloin response. The remote peer closes its end of the connection after sending the responseHello. At this point, each side can decide what to do following the spec (aka the peer missing data should start syncing the chain or incompatible peers are disconnected).Does this clarify the initial handshake?