The reason for the erratic behavior was that the tcp implementation
silently drops window update messages after noting the update but without
triggering any data send event. Before the new TCP patches were applied,
the implementation relied on a retransmission timeout to trigger a send event
after a window update. One of the new patches dealing with the ideal timer
changed the semantic of the restransmit function call and caused the behavior
witnessed.
But a retransmission timeout is not the correct solution to window update. In
fact a retransmission is not a desired effect of window update. So in the patch
attached, I have changed the behavior of the implementation to immediately
acknowledge the window update (along with data from SendQueue) and thus solving
the problem of complete halt in data transmission.
The patch also has the changes re-implemented that were reverted back but had
nothing to do with the issue at hand. For the time being, I have also removed
the "ideal timer" part from the patch (although it wasn't creating any
conflict). I initially decided to implement the ideal timer using the same
timer used for retransmission to avoid adding an additional timer. But as I
have seen, it can be problematic. So I will be re-implementing the ideal timer
and thus it was not included in this patch.
Signed-off-by: Augustin Cavalier <waddlesplash@gmail.com>
Fixes#13704.
272e1a2f97