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

[email protected] (Simon Goldschmidt) Wed, 30 Jan 2019 15:14:12 -0500 (EST)
Newsgroups gmane.network.lwip.cvs
Message-ID <[email protected]>
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 <[email protected]>
Date:   Wed Jan 30 21:14:01 2019 +0100

    revert accidentally committed files

commit b1d3dcb8d7f7bd93d91e4f070571bb7afbfab279
Author: Solganik Alexander <[email protected]>
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 <[email protected]>

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

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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.