[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[lwip-devel] [bug #32417] TCP_OVERSIZE seems to have problems with (fast
[lwip-devel] [bug #32417] TCP_OVERSIZE seems to have problems with (fast-)retransmission
Wed, 07 Dec 2011 19:02:43 +0000
Mozilla/5.0 (Macintosh; Intel Mac OS X 10_7_2) AppleWebKit/535.7 (KHTML, like Gecko) Chrome/16.0.912.59 Safari/535.7
Follow-up Comment #7, bug #32417 (project lwip):
> Is that so? If so, that wouldn't be a bug of TCP_OVERSIZE but a general
> problem with retransmission. I.e. segments should be resent as long as they
> contain unacked data. The remote host is free to send ACKs to any amount of
> data, so that could always hit us in the middle of a segment. By adding
> change (TF_SEG_SENT flag), I fear we would only hide a more general
If you want to fix it differently, then that should be filed as a separate
I think it's pretty unlikely for a host to acknowledge just part of a packet
it received (i.e., it actually received a frame containing sequence 100 - 200
but decides to ack only to 150), but it certainly would be allowed. I
it could happen if it only acks once the upper layers read the stream, and
application reads in smaller chunks and stops without closing.
If you modified a host to do that, and LwIP then appended past sequence 200
the same pbuf, I think LwIP would never retransmit it.
It's been awhile so I don't remember all of the analysis. I did write the
description at the time, though. If a segment is allowed
to grow after it's sent once, it'll never get resent. I think it's
a clean enough fix to just not append to a segment once it's been sent.
Otherwise you could do a fix to trim pbufs once they get acked. However,
the pbuf may already be in use by the driver (for a re-send) so modifying
it once it is sent may cause problems. I think once a pbuf is given to
a driver, it shouldn't be changed, even just to increase the length.
I agree with you on 1 and 3.
Reply to this item at:
Message sent via/by Savannah