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

[trex7]

Hi Simon,
I guess we have a communication problem here. Your proposal is exactly what
I'm doing. There was a mistake in  displaying my code sample. The line
tcp_recved() was a part my comment. This is done in the
"do_the_copy_to_buffer_task()" pseudo code. The tcp_recved() is not called
directly in the tcp receive callback. tcp_recved() is only called when there
pbuf is copied to  buffer.

the "do_the_copy_to_buffer_task()"  It look something like this:

if(GetBufferFreeSize) //  are there free space in the buffer?
{
   pbuf_copy_partial (xxx, buf, GetBufferFreeSize, xxx );
   tcp_recved(xxx, GetBufferFreeSize);
   copy_to_buffer(buf, GetBufferFreeSize);
}

It is by far not complete but I guess you understand what I mean.

Back to my question: Lets say my buffer is full. the tcp callback is called
by lwip. I cannot process the bpuf so I will not call tcp_recved(). What
should I do will the pbuf? Or do you think the tcp receive callback is not
called at all?

Trex





 







address@hidden wrote:
> 
> trex7 <address@hidden> wrote:
>> -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.
> 
> 
> Consider this:
> - your buffer size = 10000 bytes
> - TCP_WND (tcp window) = 5000 bytes
> - TCP_MSS (segment size) = 500 bytes
> 
> 1. Buffer is empty, RX windows size = 10000
> 2. server sends a full window (5000 bytes)
>  -> to the server, the window is full, cannot send more
> 
> Your code (or as I think it is):
> 3. data received (buffer now contains 5000 bytes, 5000 bytes free),
> tcp_recved() called
>  -> data is ACKed, window is updated
>  -> to the server, the window is empty -> can send another 5000 bytes
> 4. server sends a full window (5000 bytes)
>  -> to the server, the window is full, cannot send more
> 5. data received (buffer now contains 10000 bytes, 0 bytes free),
> tcp_recved() called
>  -> data is ACKed, window is updated
>  -> to the server, the window is empty -> can send another 5000 bytes
> 6. server sends a full window (5000 bytes)
>  -> to the server, the window is full, cannot send more
> 7. you deny the first segment, lwIP drops the rest of the segments (4500
> bytes "lost") *THIS IS BAD*
>  -> server gets an ACK to the first segment only
> 8. lwIP polls your recv callback every 250ms, eventually you take the
> packet and call tcp_recved()
>  -> the server has to retransmit the 4500 bytes previously lost
> 
> My proposal:
> 3. data received, tcp_recved() called
>  -> data is ACKed, window is updated
>  -> to the server, the window is empty -> can send another 5000 bytes
> 4. server sends a full window (5000 bytes)
>  -> to the server, the window is full, cannot send more
> 5. data received (buffer now contains 10000 bytes, 0 bytes free), do *not*
> call tcp_received, as you cannot buffer any more data
>  -> ACK is send, but the window is still full, so the server does not send
> any more data
> 6. your application consumes 1000 bytes from the buffer
>  -> there are now 100 bytes free in the buffer, call tcp_received(1000) to
> tell the server it can send 1000 bytes
> etc.
> 
> -> In summary:
> - as long as the number of free bytes in your buffer is >= TCP_WND, call
> tcp_recved() from the recv callback
> - when the number of free bytes in the buffer is < TCP_WND (before
> dequeueing), call tcp_recved() after you dequeued from the buffer.
> That way, the server never sends more data than you can 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-tp33420167p33428781.html
Sent from the lwip-users mailing list archive at Nabble.com.