Fix fast retransmit #233
Fix fast retransmit #233
Conversation
pothos
force-pushed
the
fix-fast-retransmit
branch
from
b9a3c39
to
11f4ce6
Compare
|
I've updated and expanded the tests. |
This fixes entering a loop when both endpoints are stuck in retransmission. smoltcp-rs#224
pothos
force-pushed
the
fix-fast-retransmit
branch
from
11f4ce6
to
277e7a3
Compare
|
I think some of the calulation youre thinking about regarding Or at least this is where the actual length of the package is calulated based on the SYN and FIN bits. |
| @@ -143,7 +143,7 @@ impl Timer { | |||
|
|
|||
| fn set_for_retransmit(&mut self, timestamp: Instant) { | |||
| match *self { | |||
| Timer::Idle { .. } => { | |||
| Timer::Idle { .. } | Timer::FastRetransmit { .. } => { | |||
There was a problem hiding this comment.
Could you explain this decision?
If we're already doing a fast retransmit, why would we change it to a retransmit with a timeout?
Is it related to exiting from the fast retransmit state?
There was a problem hiding this comment.
Yes, set_for_retransmit is called after all was send out, so this leaves the fast retransmit mode and should wait now instead of looping in poll.
|
@m-labs-homu r+ |
|
📌 Commit 277e7a3 has been approved by |
Closes: #233 Approved by: whitequark
|
💔 Test failed - status-travis |
|
@m-labs-homu retry |
|
☀️ Test successful - status-travis |
Small notice: The test
ack_number < self.remote_last_seqis simple and used in https://github.com/google/netstack/blob/master/tcpip/transport/tcp/snd.go#L473 (reverse asack == s.sndNxt) but maybe this does not work for sending FIN as calculated e.g. byseq_to_transmit(). Maybe more robust would be using a version ofseq_to_transmit_from(ack_number)withack_numberinstead ofself.remote_last_seqto calculate if there is something to be sent?Edit: Never mind, since
self.local_seq_nois used to setself.remote_last_seqthis calculation does not matter.