Oleg,
In your original post, you mentioned that your application reads some data out of the buffer, but this doesn't result in a window update. This is because LwIP waits until 1/4 of the window has been opened up. There is a setting that controls the update threshold in opt.h. You can adjust this to match your use case. /** * TCP_WND_UPDATE_THRESHOLD: difference in window to trigger an * explicit window update */ #ifndef TCP_WND_UPDATE_THRESHOLD #define TCP_WND_UPDATE_THRESHOLD LWIP_MIN((TCP_WND / 4), (TCP_MSS * 4)) #endif I'm also surprised that when LwIP ACKs the zero window probe, it doesn't contain the updated window value. What top-level API is your application using, sockets or Raw? With the Raw API, I believe you have to call tcp_recved() after your application receives data out of the buffer to update the window. Joel On Nov 07, 2016, at 10:03 AM, Oleg Gladyshev <[email protected]> wrote: Hi Noam, Thank you very much for your reply but I think you misunderstood me. Look at the article: https://wiki.wireshark.org/TCP%20ZeroWindow Of course my host (controlled by Windows now) sends data using quite large packets. But when device's buffer becomes full host starts periodical checking of the buffer. Windows performs it using 1 byte packets called "Zero Window Probe packet" and we can't affect this behavior. Hi, First of all if you have control over the host machine avoid sending 1 byte. This is not efficient. I suggest adding a dual mechanism. Defining size and/or timeout. I mean adding some mechanism that counts bytes ready to be sent. If you have more than X Bytes you send them out. Also add a timeout. Meaning if you have collected less then X bytes but a time period has elapsed since the last send, send it anyway. This way you force the sender to send a minimum sized buffer and not send out 1 byte at a time with a large overhead... At your device side you probably have a DMA collecting data. You may modify the code and check How many bytes have you received. Similar to the above mechanism. If you got less than some limit you do not allocate a pBuf ... only if you have a minimum data size or a time difference from last data handling you allocate a pBuf, copy data to it and let the TCP stack handle it. BR, Noam. -----Original Message----- From: lwip-users [mailto:[email protected]] On Behalf Of Oleg Gladyshev Sent: Monday, November 07, 2016 3:23 PM To: [email protected] Subject: [lwip-users] Zero window and refused data problem Hi all, I develop a device which receives data from host machine using TCP (LwIP 1.4.1). Host sends data continuously queuing it to the controller. Controller process data as fast as possible, but data process time is not determined. it can be from milliseconds to hours. And I wish to use TCP/IP incoming buffer as buffer for the data. In my case TCP window on the device becomes full very often. Sometimes device's application receives from the TCP stack portion of data less than TCP windows size. This case LwIP doesn't update receive window leaving it zero. But the device able to receive some bytes now. And when the host sends 1 byte ZeroProbe packet device receives it. For this one byte LwIP allocates new pbuf structure and sends it to application using sys_mbox_xxx call. I use fixed-size mbox queues so after some probe packets from the host mbox becomes full and refuses new data. tcp_input notices this and tries to deliver refused data to the application every time it called. But if application still refuses new data tcp_input() doesn't send ACK to the host! And host disconnects after some tries. Making my mboxes dynamically doesn't solve the problem because in general we can waste all RAM with (TCP_WND-1) pbuf structures for every incoming byte from window probe packets. I think it would be better to ACK with previous value to the host instead of silently dropping new data. What do you think about the issue? What is the best way to avoid disconnects in my project? -- Best regards, Oleg _______________________________________________ lwip-users mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/lwip-users _______________________________________________ lwip-users mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/lwip-users --- С уважением, Олег ([email protected]) _______________________________________________ lwip-users mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/lwip-users
_______________________________________________ lwip-users mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/lwip-users
