Re: [lwip-users] Zero window and refused data problem

[Noam Weissman]

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:address@hidden On Behalf Of Oleg Gladyshev
Sent: Monday, November 07, 2016 3:23 PM
To: address@hidden
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
address@hidden
https://lists.nongnu.org/mailman/listinfo/lwip-users