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

[trex7]

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

Yes, I return ERR_OK. 

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

On my opinion both cases are technically the same, because I only call
tcp_revced() when I have enough space on my buffer, meaning if the buffer is
full ->  I cannot process the incomming pbufs. Thats exactly what also
happens if I will call tcp_revced() only when I *PROCESSED* (after
dequeueing it), meaning the buffer is full -> I cannot process the incomming
pbufs. In both cases I need to do something with the incomming pbuf, whether
ignore it or free it. As I've posted ealier both seems to work fine. I
tested both case for few hour.  

>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.
-I dont realy understand what you mean. I think, the scenario that I cannot
process the incomming pbufs will always be there and I hope that lwip has a
mechanism to handle this scenario without losing any  data. 

Please correct me if I misunderstood anything. Thanks for you patience.
Trex






address@hidden wrote:
> 
> 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
> 
> _______________________________________________
> 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-tp33420167p33427381.html
Sent from the lwip-users mailing list archive at Nabble.com.