lwip-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lwip-users] Out of sequence packets lost between TCP and HTTP serve


From: Johan Borkhuis
Subject: Re: [lwip-users] Out of sequence packets lost between TCP and HTTP server
Date: Fri, 23 Feb 2018 14:45:25 +0100
User-agent: Mutt/1.5.20 (2009-06-14)

Simon,

Thank you for your quick response.

The thing I did not implement was the chained pbufs. I checked and implemented
this and now I receive all frames. In the example in my original email after
receiving frame 13 I now follow the pbuf->next, and the missing packets are
chained there. So I am now receiving all data in the right order.

The issue with forward ACK is AFAIK an indication to the client that it can
continue with sending the next frame, and no need to send frames between the
missing one (13) and the next one (21).

Again, thanks for your help!

Regards,
Johan

On Fri, Feb 23, 2018 at 12:00:43PM +0100, Simon Goldschmidt wrote:
> Johan Borkhuis wrote:
> > [..]
> > I am missing data with the size of one TCP_WND-1, so 7 frames. The data was
> > transmitted over the line, but at one moment the internal buffers are full 
> > and I
> > start seeing duplicate ACKs.
> 
> What internal buffers are you talking about? lwIP pbufs or buffers in your 
> POST processing?
> 
> > [..]
> > Why are the packets between 13 and 20 not received by the HTTP server?
> 
> A better question is: why is packet 21 ACKed before it is sent?
> That indicates there's something wrong.
> 
> > Do I
> > need to set another callback to process the out-of-sequence packets or is
> > there another option that can be set to make sure the packets are passed to
> > the application?
> 
> No. This should just work. Pbufs are passed in sequence to your application.
> You don't get a pbuf passed twice though: once it gets passed to your recv 
> callback, you need to handle it or it is lost.
> 
> Also, you have to watch out for chained pbufs. Especially, pbufs are chained 
> after OOSEQ processing even if they aren't otherwise.
> 
> Simon
> 
> _______________________________________________
> lwip-users mailing list
> address@hidden
> https://lists.nongnu.org/mailman/listinfo/lwip-users



reply via email to

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