-
Notifications
You must be signed in to change notification settings - Fork 1.1k
swarm: connection management behaviours can lead to inconsistent state #4870
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
Comments
Thank you for documenting this. Unfortunate that we did not catch this earlier. Two alternative suggestions:
|
I don't think (1) is a suitable option as it makes it impossible to implement block lists for example. In combination with a default, non-zero idle timeout, perhaps just passing data to the handler in Or, we simply specialise the "connection just got established"-case. Arguably, a user should be able to react to the I think you suggested something like this at some point @mxinden when we talked about the idle-connection-timeout. What do you think of a 1(?)-second, unconfigurable delay before considering a just-established connection idle? It feels a bit wrong because picking a delay is inventiably sensitive to the environment we are running it. Yet, it seems the current situation is not good and I'd like to change the above to |
In #4777, we discovered that a "connection management" behaviour like
libp2p-connection-limits
can lead to inconsistent state if it is not applied "first" in the tree of behaviours.That is because the
handle_
functions take&mut self
and thus allow modifying the state of aNetworkBehaviour
, potentially pre-loading a handler with state. If a behaviour deeper in the tree ends up rejecting the connection, that state is lost.Preloading handlers is useful to ensure they don't "instant timeout" based on keep-alive after a connection has been established.
The underlying design issue here is that the composition of
handle_
functions leads to an inconsistent view across the state ofNetworkBehaviour
s. By having them take&self
, this issue would not occur (unless the user users internal mutability but that we can't guard against).Somehow, we'd need to find a way to still pass data to the handler but only in case the connection is fully established. Perhaps we should find a way to mitigate the "instant shutdown" in a different way by not starting the
Connection
task until theConnectionEstablished
event has been dispatched to the behaviour?The text was updated successfully, but these errors were encountered: