[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[lwip-devel] [bug #20511] No persist timer
From: |
Tamas Somogyi |
Subject: |
[lwip-devel] [bug #20511] No persist timer |
Date: |
Fri, 28 Nov 2008 10:06:20 +0000 |
User-agent: |
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.0.4) Gecko/2008102920 Firefox/3.0.4 |
Follow-up Comment #15, bug #20511 (project lwip):
(A) This modification below resends the unacked segments till the send window
allows.
tcp_zero_window_probe(...)
{
... some variables ...
//INSERTION-->
u32_t wnd;
u8_t resent_flag;
//<--INSERTION
... some LWIP_DEBUGF ...
seg = pcb->unacked;
//INSERTION-->
/* While unacked segment is available and window allows to (re-)transmit as
a whole */
wnd = LWIP_MIN(pcb->snd_wnd, pcb->cwnd);
resent_flag = 0;
while (seg != NULL &&
ntohl(seg->tcphdr->seqno) - pcb->lastack + seg->len <= wnd) {
LWIP_DEBUGF(TCP_OUTPUT_DEBUG,
("tcp_zero_window_probe: retransmitting segment %"U32_F"n",
ntohl(seg->tcphdr->seqno)));
/* Resend segment now */
tcp_output_segment(seg, pcb);
resent_flag = 1;
seg = seg->next;
}
/* If there was at least one retransmitted segment, no need for zero-probe,
so return */
if(resent_flag)
return;
//<--INSERTION
if(seg == NULL)
seg = pcb->unsent;
...
}
This is the only change I made in tcp_out.cpp.
I can confirm using Wireshark that 9-10 segments are retransmitted when
segment lost.
I tested in my test environment and it was running well over the night
(~16hrs) without breaking the socket.
Therefore I decided to use it in my code - if you accept it, please commit
also into lwip CVS repository.
(B) Please note that the above is a solution for small sender window only,
and not for zero receiver window. I cannot test the latter because it doesn't
happen in my system. However I tried to set TCP_ACK flag of the 1-byte probe
and then I got reply from the receiver. But despite of this, lwip sent out the
1-byte probe again, therefore I suspect that some further checks needed, so
would be essential to test that part in
real situation.
WRT tcp_receive, I don't really know the meaning of that condition. It's just
an
intuitive fix because it looks like the following pattern:
if ((a1 < a2) ||
(a1 == a2 && b1 < b2) ||
(a1 == a2 && b1 == b2 && c1 < c2))
But if "a1 == a2" is missing from the third line, the expression can be true
in case of
a1 > a2 which is probably unwanted.
_______________________________________________________
Reply to this item at:
<http://savannah.nongnu.org/bugs/?20511>
_______________________________________________
Message sent via/by Savannah
http://savannah.nongnu.org/