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

[Simon Goldschmidt]

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