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