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: Bill Auerbach
Subject: Re: [lwip-users] Partial read on receive callback
Date: Fri, 13 May 2011 13:05:01 -0400

Maybe it will help you to know how I do what you’re doing, since I’m in the same situation.  But more, I sometimes get a packet (which needs to be complete) which then says here’s a variable part of the remainder of the application function (which the first packet has the size of).

 

My tcp_received takes the incoming pbufs and uses pbuf_cat to combine them to a head packet (which is kept in a static variable).  Each tcp_received calls back to the application with the total length of this pbuf chain.  If there is enough data, the application calls a function ‘TcpRead(u8_t *ptr, u32_t len)’.  This function copies len bytes to ptr from the pbuf chain, deleting pbufs as each one is completely read.  To leave data behind, I do unfortunately have to modify the latest pbuf payload, len and tot_len but this allows the pbuf_cat to continue to work for incoming tcp_received calls and the next read from the application to find the leftover (and new) data.

 

Actually, I just checked and there is (is it new???) a pbuf_copy_partial which does what I did in my own code.  I will switch to use this function.

 

This method allows me to read data into a contiguous memory block which was a requirement for me.

 

Bill

 

From: address@hidden [mailto:address@hidden On Behalf Of Enrico Murador - Research & Development - CET
Sent: Friday, May 13, 2011 5:14 AM
To: address@hidden
Subject: Re: [lwip-users] Partial read on receive callback

 

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);
- 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...

Am I supposing right?

Thank you very much
Enrico


reply via email to

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