Skip to content

Clean termination of revision loop

Luke Champine requested to merge stop into master

The host now sends modules.StopResponse to the renter when it wishes to gracefully terminate the revision loop. The renter will respect this by disconnecting without error.

I still don't like this. It's bizarre that proper use of the host-renter protocol should require repeatedly disconnecting and reconnecting for no reason. There are many reasons why a host would want to terminate the revision loop: shutdown, changed settings, DoS concerns. But disconnecting for no reason forces the renter to reconnect, and this requires ugly and confusing logic. (The situation is even worse when downloading: due to the way the concerns are separated, there's no easy way to reconnect at all. This means that files taking longer than 20 minutes to download cannot currently be downloaded.) We should ask what we stand to gain from enforcing this hard limit. Assume that the renter will immediately try to reconnect. The gain here is that we have a brief period between disconnect and reconnect, where we can use some criteria to judge whether we should accept the reconnection. But at present (to my knowledge) no such criteria is implemented, and if we wanted to implement it, we could do so inside the revision loop, rather than outside.

In short: gracefully terminating with StopResponse is fine, but the implication that the renter should immediately reconnect is not.

Merge request reports