lwip-users
[Top][All Lists]
Advanced

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

Re: [lwip-users] Partial read on receive callback


From: Tomas Hruby
Subject: Re: [lwip-users] Partial read on receive callback
Date: Fri, 13 May 2011 11:24:08 +0200
User-agent: Mutt/1.5.20 (2009-06-14)

On Fri, May 13, 2011 at 11:13:46AM +0200, Enrico Murador - Research & 
Development - CET wrote:
> Dear Kieran,
> Thank you for the reply.
> >The callback won't be called again until there is new data, and the data
> >passed to the callback will only be the new data; it won't (I think)
> >pass you the data you've been given already as you were hoping.  I'm
> >afraid you have to create a list of the data you're interested in until
> >you've got enough to process.  You don't need to copy it, as this is the
> >point of tcp_recved() - it allows you to keep hold of the data until
> >you've finished with them, even if that's not straight away during the
> >callback.  Once you've processed and finished with the data, call
> >tcp_recved() and the stack will be allowed to reuse those buffers.
> >
> >Kieran
> >
> It is ok for me to keep the data on the packet buffers, but I'm
> concerned with the
> possibility that at the end of the buffer chain I will find a
> "partial" message; in that
> case, If I understand well, I have two choices:
> 
> - Leave all the data in the buffers by not calling tcp_recved() and
> waiting for another
>   chunk of data, hoping that at that time the buffers contains a
> "complete" sequence
>   of messages (some of wich I could have already processed);

I am afraid that if the message is too long you might wait forever as
the data received on your side are not ACKed to the sender if you
don't call tcp_recved(). And the sender may not be allowed to send
more before it gets ACK.

> - Copy the part of the uncomplete message in a separated buffer (and
> advertise
>   the stack that I have processed all the data), chaining it with
>   the new data that will arrive the next time...

That's the safer option.

        T.



reply via email to

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