trex7 <reynaldo.k...@istgroup.de> 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 _______________________________________________ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
