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

[Simon Goldschmidt]

trex7 <address@hidden> wrote:
> 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().

... and you return ERR_OK? In that case, the server won't resend the packets an 
you'll lose them.

> 2. I free the pbuf with pbuf_free(). As always no calling of tcp_recved().

In that case, I guess you'll also lose the packets.

> 3. I returned ERR_INPROGRESS and no pbuf_free(). And no calling of
> tcp_recved(). (I will try to return  ERR_MEM today)

That will result in new packets being discarded -> unnecessary retransmissions 
will get necessary. As a fallback if your buffer is really full that's the best 
solution of the three.

However, you should design both your buffer size and RX windows size in a way 
that this is not necessary - that's what TCP's sliding window mechanism is 
meant for.

> 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? 

No. Any buffer you free is lost and won't be retransmitted. Freeing the pbuf 
and returning != ERR_OK is an API violation (as returning != ERR_OK means "I 
cannot deal the pbuf and haven't touched it").

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

NO! You should only call tcp_recved() *AFTER* you have *PROCESSED* the data, 
not when you enqueued it! Calling tcp_recved() effectively means telling the 
server "go on sending data, I can handle it" - you don't want to do that when 
enqueueing data into the buffer but when dequeueing it from the buffer!


Simon
-- 
Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir
belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de