-
Notifications
You must be signed in to change notification settings - Fork 442
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Dial queue timeout for multiple multiaddresses incorrectly used for each connection separately #2368
Comments
@achingbrain can you please look into it? |
@achingbrain could you take a look at this ? Most auto dials are failing because of it |
@akim-bow what kind of addresses are you having problems with? The example you gave was If you know certain addresses are going to be unreliable or slow, you can also pass an addressSorter as part of the |
@achingbrain I'm having the same issue when running nodes in local environment. When dialing a peer, these are the addresses found in the peer store:
The first address is not reachable, while the other two are. The dialer fails after |
My concern with the proposed solution is that having separate timeouts for individual addresses could lead to very long dial times. I wonder if we could be smarter with the dialling, for example if the IP address of the target multiaddr is a class A private network address, deprioritise or entirely skip dialling it unless the current node also has a class A private network address in the same logical network? |
Although sorting and filtering addresses is a good option, as a user I would still expect the dial function to attempt dialing all provided addresses. |
Version:
[email protected]
Severity:
Medium
Description:
If remote peer proposes multiple multiaddresses, e.g.
[/dns/nox-1, /ip4/10.50.10.10, /ip4/127.0.0.1]
(only the last one is reachable by default),libp2p
will try to connect to them one by one. As you can see in the source code, the shared signal is created and used in every attempt to dial multiaddresses. Hence, the first address could take up all the time until the signal aborts and other addresses would be dropped without an attempt to connect to them.I'm proposing to use 2 separate signals - first one for batch of multiaddresses, the second one for each multiaddress separately. It will solve the case when a peer provides multiple adresses and only some of them are actually valid. If the description isn't clear enough i can try to build simple reproduction example.
The text was updated successfully, but these errors were encountered: