fix(request-response): don't keep duplicate addresses

[b-zee]

Description

Resolves: #4699.

Notes & open questions

In kad, there is a special Addresses struct that might be worth reusing for this functionality.

I will make further CHANGELOG edits etc if this fix is thought to be sensible.

Change checklist

• I have performed a self-review of my own code
• I have made corresponding changes to the documentation
• I have added tests that prove my fix is effective or that my feature works
• A changelog entry has been made in the appropriate crates

[joshuef]

Nice one. This looks to have been a wee mem leak for us. We've been doing add_server on every Identify event and been leaking decent chunks of memory over time. 💪

[mxinden]

How about using a HashSet instead?

modified   protocols/request-response/src/lib.rs
@@ -337,7 +337,7 @@ where
     /// reachable addresses, if any.
     connected: HashMap<PeerId, SmallVec<[Connection; 2]>>,
     /// Externally managed addresses via `add_address` and `remove_address`.
-    addresses: HashMap<PeerId, SmallVec<[Multiaddr; 6]>>,
+    addresses: HashMap<PeerId, HashSet<Multiaddr>>,
     /// Requests that have not yet been sent and are waiting for a connection
     /// to be established.
     pending_outbound_requests: HashMap<PeerId, SmallVec<[RequestProtocol<TCodec>; 10]>>,

[thomaseizinger]

How about using a HashSet instead?

modified   protocols/request-response/src/lib.rs
@@ -337,7 +337,7 @@ where
     /// reachable addresses, if any.
     connected: HashMap<PeerId, SmallVec<[Connection; 2]>>,
     /// Externally managed addresses via `add_address` and `remove_address`.
-    addresses: HashMap<PeerId, SmallVec<[Multiaddr; 6]>>,
+    addresses: HashMap<PeerId, HashSet<Multiaddr>>,
     /// Requests that have not yet been sent and are waiting for a connection
     /// to be established.
     pending_outbound_requests: HashMap<PeerId, SmallVec<[RequestProtocol<TCodec>; 10]>>,

+1 for using a HashSet. Long-term, we should solve this by adding a PeerStore behaviour: #4103.

[thomaseizinger]

Thanks! Can you address the clippy failure?

[b-zee]

Fixed the clippy lint.

Is v0.53.0 set to be released soon? Or, possibly, is there a patch release that this could part of soon? Thanks for all the work!

[thomaseizinger]

Fixed the clippy lint.

Is v0.53.0 set to be released soon? Or, possibly, is there a patch release that this could part of soon? Thanks for all the work!

If you backport it to the v0.52 branch, I can cut a patch release :)