[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[lwip-commits] [SCM] lwIP - A Lightweight TCPIP stack branch, master, up
From: |
Simon Goldschmidt |
Subject: |
[lwip-commits] [SCM] lwIP - A Lightweight TCPIP stack branch, master, updated. STABLE-2_1_0_RELEASE-231-gcbc80a0 |
Date: |
Wed, 30 Jan 2019 15:14:12 -0500 (EST) |
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
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- [lwip-commits] [SCM] lwIP - A Lightweight TCPIP stack branch, master, updated. STABLE-2_1_0_RELEASE-231-gcbc80a0,
Simon Goldschmidt <=