Skip to content

Conversation

@izderadicka
Copy link
Contributor

For a while I was observing how dead peers are retried and found couple of thing, which I think are sub-optimal:

  • when incoming peer has error, then on_peer_died is called and eventually peer is scheduled as outgoing, The SocketAddress in this case has outgoing port of peer I think, so retry with it as outgoing does not make sense to me.
  • scheduled retries stay pending even after the download of torrent is finished ( often with long waiting times). They keep popping out long after then. I think it would be better to cancel them after download finishes.

This not final PR - rather a sketch to illustrate my findings. There is probably better way to solve it.

Copy link
Owner

@ikatson ikatson left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Put some comments. Also recently the e2e test was very stable, but it broke in this PR, which makes me think it has a bug

@izderadicka
Copy link
Contributor Author

If you don't mind, I'll play more around this PR - remove first cancellation as it it clearly wrong now and look only on preventing retry on failed incoming peers.


if self.incoming {
// do not retry incoming peers
debug!("incoming peer {handle} died, not re-queueing");
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: at least for the sake of consistent style please put handle into a parameter, e.g. debug!(peer=handle, "incoming peer died, not re-queueing");

@izderadicka izderadicka marked this pull request as ready for review September 22, 2024 07:18
@ikatson ikatson merged commit f7a8124 into ikatson:main Sep 22, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants