-
Notifications
You must be signed in to change notification settings - Fork 126
Conversation
This change will decrease the chance we're not reading from socket when a packet arrives (i.e. decrease the chance to a packet loss event occurs). It shouldn't be needed, but rust-utp isn't being very reliable. At some point, it might be required to patch rust-utp to update the congestion control algorithm and the strategy to when resend a packet.
This is a mechanism to protect from unreliability of rust-utp. Currently, timeout is 5min, but can be changed to better suit Routing needs. Thanks to only high-level events being detected (and `cbor::Decoder` taking ownership of our chance to intercept "less than a whole message received" events like "a bunch of bytes received"), this mechanism may not be optimal if the crust user is hoping to send bigger messages.
r? @inetic (maidsafe_highfive has picked a reviewer for you, use r? to override) |
r? @maqi |
could you link the required rust-utp updates as well ? And, the PR #442 is preferred to be merged before this PR, |
I started working on this after I submitted this PR. The idea is to not leave crust in a so bad situation while we fix the real issue within rust-utp.
Well, the current issues won't happen because if rust-utp misbehave, crust will issue a "connection loss" event. We "just" exchange one error for another. Connection loss is expected in the wild and layers above crust will have to handle them anyway. With the patch, they'll have the chance to not hang thanks to misbehaving rust-utp. |
If so, I will prefer merge your rust-utp work first then merge this PR, or merge them at the same time.
However, the current crust network test only covers TCP, and this In summary, could you please change the title of this PR to WIP, and once your rust-utp work is done, put a summary report here so this PR can be properly verified? |
This updates #439 by adding more protection on the crust side of things. To close the issue for good, updates are also required on the rust-utp side.