On 21 Nov 2011, at 15:45, Brian McFarland wrote: > So say my tcp_recv() callback gives me three pbufs chained: A->B->C. If I > need to save some of the data for later, what’s the intended mechanism for > freeing A but not B->C? Seems like could be accomplished either by > pbuf_ref(B) and then pbuf_free(A) --OR-- pbuf_dechain(A) followed by > pbuf_free(A). Is that correct? Is either method *more* correct (i.e. always > better), do both methods have their own advantages?
I'd have to look at the source to be sure, but I would probably go for the dechain method. > On a related note, if I don’t want to tcp_recv() any more data until > processing the data in B->C, can I just postpone calling tcp_recved()? No. That will eventually result in no more data being passed to your callback as it will prevent the sender from transmitting more, but not on a timescale that you are hoping for. tcp_recved() allows lwIP to re-advertise the memory to the sender so it can transmit more packets, but if there were others already in flight or internal to the stack they will carry on being delivered. There isn't an easy way with the raw API to stop the stack like that. It is this sort of feature that the higher layer APIs provide (together with the associated overhead). Kieran _______________________________________________ lwip-users mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/lwip-users
