swarm: implement blackhole detection#2320
Conversation
5a1b295 to
0e6beee
Compare
98ce244 to
57de43c
Compare
|
@marten-seemann This doesn't implement happy eyeballs for TCP since the delay required for that to be effective is about 700ms. That feels too long to me. We can implement happy eyeballs for TCP separately where we introduce a mechanism to notify the worker loop that a connection has been established and security and muxer selection is in progress. |
f893840 to
8b8e686
Compare
|
Should we make the changes to the dial prioritization logic in a follow-up PR? Would be nice to disentangle it. |
|
We probably should also add some metrics to our swarm dashboard. What about this: for both IPv6 and UDP, we'd show a row containing
|
|
Completely agree with the metrics suggestion.
might be difficult since we probe based on number of requests(every nth request is allowed). It should be fine to make this number of requests till next probe. |
8b8e686 to
72e306d
Compare
72e306d to
1b90ff6
Compare
1b90ff6 to
ab91d42
Compare
ab91d42 to
5c1b358
Compare
bbdcb0a to
b872a85
Compare
|
@marten-seemann |
bb41137 to
cb803ec
Compare
|
Updated the PR to do address filtering and probing for reevaluating black hole state at a peer level. |
9d7ee69 to
555a36a
Compare
| // it must be an error -- add backoff if applicable and dispatch | ||
| if res.Err != context.Canceled && !w.connected { | ||
| // ErrDialRefusedBlackHole shouldn't end up here, just a safety check | ||
| if res.Err != ErrDialRefusedBlackHole && res.Err != context.Canceled && !w.connected { |
There was a problem hiding this comment.
Should this go in error log? If we're not noisy about it, we'd miss this bug if we ever introduce it.
821ee14 to
8436037
Compare
8436037 to
41808df
Compare
|
Add the description in the release issue highlights while its fresh #2326? |

No description provided.