|
From: | Oleg Gladyshev |
Subject: | Re: [lwip-users] Zero window and refused data problem |
Date: | Tue, 08 Nov 2016 09:10:45 +0300 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.7.0 |
Hi Joel,Data being sent to the device in fact are commands. Commands have different sizes and different execution time. Device reads commands from the buffer one by one and executes them. So if the buffer was really full and after that device read a long time command with size less than the TCP window update threshold I get a described situation. Yes, this is my case. And I think that LwIP is correct too. No, real windows is not zero. Yes, you right, but the problem a little deeper. LwIP knows about window size, but really has not own buffer for received bytes. Instead it sends every FRAGMENT (as pointer) to application's mail box. In other words I must set window size in bytes for LwIP, but must make mailbox operated with fragments of unknown length. In worst case my mailbox must be able to store every 1-byte fragment. This wastes RAM. Moreover communication will completely hangup on mailbox overflow. See an example below: Current LwIP behavior: -> Seq=1, L=100 <- Ack=101, W=0 -> Seq=101, L=1 (Zero window probe) <- Ack=102, W=0 - this is a current LwIP behavior even if fragment was not really accepted by mailbox. This case the fragment hangs in refused_data pointer and no further ACKs are possible. -> Seq=102, L=1 -> Seq=102, L=1 -> Seq=102, L=1 -> RST It would be better if LwIP didn't send ACK for the fragment it really can't accept: -> Seq=1, L=100 <- Ack=101, W=0 -> Seq=101, L=1 (Zero window probe) <- Ack=101, W=0 !!! Note that ACK=101, not 102 as in previous example. 1 byte was rejected by mailbox and stored to refused_data pointer. We will ignore all further data but ACK incoming packets -> Seq=102, L=1 <- Ack=101, W=0 -> Seq=102, L=1 <- Ack=101, W=0 .... Such behavior will not cause connection reset.
-- С уважением, Олег Гладышев |
[Prev in Thread] | Current Thread | [Next in Thread] |