[identify] Implement /ipfs/id/push/1.0.0 alongside some refactoring. #1999
Conversation
* Implement /ipfs/id/push/1.0.0, i.e. the ability to actively
push information of the local peer to specific remotes.
* Make the initial delay as well as the recurring delay
for the periodic identification requests configurable,
introducing `IdentifyConfig`.
|
Sorry for the delay here @romanb. I will take a look later today. |
There was a problem hiding this comment.
Changes look good to me. Thanks for the clean patch.
I wonder whether libp2p-identify should (by default?) automatically initiate pushes to its peers on inject_new_listen_addr, inject_expired_listen_addr and inject_new_external_addr.
If I understand correctly, this would be in line with the specification.
When a peer's basic information changes, for example, because they've obtained a new public listen address, they can use identify/push to inform others about the new information.
Co-authored-by: Max Inden <[email protected]>
Co-authored-by: Max Inden <[email protected]>
I can give that a try in a follow-up PR. It didn't occur to me to do that here. Thanks for the suggestion. |
Follow up pull request sounds good. Thanks for giving it a shot! Feel free to merge this pull request. |
| IdentifyHandlerEvent::Identified(remote_info))); | ||
| self.keep_alive = KeepAlive::No; | ||
| } | ||
| EitherOutput::Second(()) => {} |
There was a problem hiding this comment.
Something that came to my mind: How about emitting an event along the lines of IdentifyEvent::Pushed once a push succeeded? I would expect this to be useful for people tracking these events in a monitoring system like Prometheus. This event would serve a similar purpose to the RequestSent event in libp2p-request-response:
rust-libp2p/protocols/request-response/src/lib.rs
Lines 152 to 161 in 63512e5
In case you think this is useful @romanb I can prepare a pull request.
/ipfs/id/push/1.0.0protocol, i.e. the ability to actively push information of the local peer to specific remotes.IdentifyConfig.Closes #1136.