Re: [lwip-users] flow of lwip as a stream client

[trex7]

Thank you for answers.
I tried different cases when the buffer is full and I cannot process the
incomming pbufs
1. I just ignore them, no pbuf_free(). AND of course no tcp_recved().
2. I free the pbuf with pbuf_free(). As always no calling of tcp_recved().
3. I returned ERR_INPROGRESS and no pbuf_free(). And no calling of
tcp_recved(). (I will try to return  ERR_MEM today)
All 3 cases are working fine but I don't really know which is the proper way
of dealing with the case. So when my buffer is full should I call
pbuf_free() or not? 
I think I understand how to deal with the bpufs when I have enough buffer. I
copy the payload of the pbuf to my buffer, call tcp_revced() to tell lwip
that pbuf is processed and call pbuf_free to free the pbuf.
By the way the buffer is big enough to buffer a few seconds of audio code
depending on its bit rate of course. 

Thanks
Trex


address@hidden wrote:
> 
> mat henshall wrote:
>> I think you will also want to return ERR_MEM from your callback, if I 
>> understand the code correctly, the stack will buffer the data for you 
>> and then will try again on the next fasttmr will try delivering the 
>> data again to your application.
>>
>> This way, when your circular buffer is full, the stack will buffer up 
>> the data, and the server will stop sending data until you have cleared 
>> your circular buffer and the window is updated.
> 
> That should be a fallback only, because until you accept that packet, 
> all other packets received from the remote host (including possible 
> retransmissions) will neither get ACKed nor buffered, which results in 
> unnecessary traffic.
> 
> If you design your buffer size and TCP_WND correctly and call 
> tcp_recved() when you actually process/free pbufs (not enqueue them in 
> your buffer), there's no need to return ERR_MEM from the recv callback.
> 
> Simon
> 
> _______________________________________________
> lwip-users mailing list
> address@hidden
> https://lists.nongnu.org/mailman/listinfo/lwip-users
> 
> 

-- 
View this message in context: 
http://old.nabble.com/flow-of-lwip-as-a-stream-client-tp33420167p33427000.html
Sent from the lwip-users mailing list archive at Nabble.com.