You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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".
The text was updated successfully, but these errors were encountered:
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.
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.
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.
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".
The text was updated successfully, but these errors were encountered: