lwip-devel
[Top][All Lists]
Advanced

[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/





reply via email to

[Prev in Thread] Current Thread [Next in Thread]