Skip to content
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

How to log handshake cancelations? #147

Open
marten-seemann opened this issue Apr 6, 2021 · 4 comments
Open

How to log handshake cancelations? #147

marten-seemann opened this issue Apr 6, 2021 · 4 comments

Comments

@marten-seemann
Copy link
Collaborator

I didn't think of this back when we defined the triggers for connection_closed, but this is happening a lot in production: When dialing a new peer, libp2p races connections to that peer on all advertised addresses and transports, and uses whichever connection returns first. All the other connection attempts are canceled.

It would be nice if there was a trigger "the user aborted this connection attempt before handshake completion".

@rmarx
Copy link
Contributor

rmarx commented Apr 7, 2021

Good point!

Do you think a generic aborted trigger is enough, or would it make sense to go with something more fine-grained like aborted_racing (potentially having an aborted generic as well?)?

Would it be useful to have a way to indicate to which other connection (6-tuple?) this one "lost" in the race (and by how much etc.)? Would that need a separate event or should that be included in the connection_closed? I'd tend towards a separate event for that one myself.

@LPardue
Copy link
Member

LPardue commented Sep 8, 2022

+1, sounds useful

@rmarx
Copy link
Contributor

rmarx commented Mar 4, 2024

So, I'm still of the opinion that a trigger aborted or lost_race on connection_closed is sufficient here.

Wrt to logging the "other" connection, a connection_started event can be used for the winning connection (also supports indicating they were other protocols like TCP).

So for example, at the client, you might have 2 connection_started events (1 for TCP ipv4 and 1 for QUIC ipv4) and then 1 connection_closed with trigger aborted or lost_race for either of these to indicate the other was chosen implicitly. Alternatively, you could log 1 connection_started for the one that won, and 1 connection_closed for the loser (though I'd prefer the other option ;)).

Let me know what you think @marten-seemann @LPardue. With no further feedback, I'll add both the aborted and lost_race triggers to connection_closed with a PR and call it a day.

@marten-seemann
Copy link
Collaborator Author

I think the aborted trigger is fine. I'm not sure if we need a lost_race trigger at all.

How would an application log more details though? I could image that an application might want to add some more details, like "lost the race to connection XXX", but I don't think that's something that we need to standardize.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants