[lwip-commits] [SCM] lwIP - A Lightweight TCPIP stack branch, master, updated. STABLE-2_1_0_RELEASE-231-gcbc80a0

[Simon Goldschmidt]

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "lwIP - A Lightweight TCPIP stack".

The branch, master has been updated
       via  cbc80a09206b52bc22e4e04f9f84e9f3329a532f (commit)
       via  b1d3dcb8d7f7bd93d91e4f070571bb7afbfab279 (commit)
      from  5666f305cead2c628d13b168a9aaeb7f5578dfc7 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -----------------------------------------------------------------
commit cbc80a09206b52bc22e4e04f9f84e9f3329a532f
Author: Simon Goldschmidt <address@hidden>
Date:   Wed Jan 30 21:14:01 2019 +0100

    revert accidentally committed files

commit b1d3dcb8d7f7bd93d91e4f070571bb7afbfab279
Author: Solganik Alexander <address@hidden>
Date:   Sun Jan 6 16:43:00 2019 +0100

    tcp: don't reset dupack count upon non-empty packet receive
    
    According to rfc5681:
    
    https://tools.ietf.org/html/rfc5681
    
    Paragraph 3.2.  Fast Retransmit/Fast Recovery
    The TCP sender SHOULD use the "fast retransmit" algorithm to detect
    and repair loss, based on incoming duplicate ACKs.  The fast
    retransmit algorithm uses the arrival of 3 duplicate ACKs (as defined
    in section 2, without any intervening ACKs which move SND.UNA) as an
    indication that a segment has been lost.  After receiving 3 duplicate
    ACKs, TCP performs a retransmission of what appears to be the missing
    segment, without waiting for the retransmission timer to expire.
    
    Now consider the following scenario:
    Server sends packets to client P0, P1, P2 .. PK.
    Client sends packets to server P`0 P`1 ... P`k.
    
    I.e. it is a pipelined conversation. Now lets assume that P1 is lost, 
Client will
    send an empty "duplicate" ack upon receive of P2, P3... In addition client 
will
    also send a new packet with "Client Data", P`0 P`1 .. e.t.c. according to 
sever receive
    window and client congestion window.
    
    Current implementation resets "duplicate" ack count upon receive of packets 
from client
    that holds new data. This in turn prevents server from fast recovery upon 
3-duplicate acks
    receive.
    This is not required as in this case "sender unacknowledged window" is not 
moving.
    
    Signed-off-by: Solganik Alexander <address@hidden>

-----------------------------------------------------------------------

Summary of changes:
 contrib/examples/example_app/lwipopts.h    | 11 +----------
 contrib/ports/win32/msvc/lwIP_Test.vcxproj |  4 ++--
 src/core/tcp_in.c                          |  7 -------
 3 files changed, 3 insertions(+), 19 deletions(-)


hooks/post-receive
-- 
lwIP - A Lightweight TCPIP stack