On Fri, 2011-09-23 at 13:41 +0000, Stephen Cleary wrote: > > One solution would be to limit the amount of data ftp passes to > lwip_send. My TCP_SND_BUF is TCP_WND (== 4 * TCP_MSS, where TCP_MSS == > 1460), so it's only 5840 bytes, but I'm pretty sure lwip_send is > allowing me to queue more data than that. Is there a procedure for > detecting "how full" the send buffer is on a socket so that I can > throttle in my FTP code?
This would be my preferred solution. lwIP will allow you to have TCP_SND_BUF bytes in the send queue (i.e. not yet sent on the wire) *and* TCP_WND bytes already sent waiting for an ACK from the other end. There is another variable to control the length of the send buffer in number of packets, but I think that is less relevant to your problem. There isn't an official API to access the send queue length, but you could hack something in for debugging. A packet capture would show if you're right about the problem being that the stack can't allocate packets to send an ACK. I'm a bit dubious about this. Could it be that it couldn't allocate memory to post an mbox message to the sockets API instead? The LWIP_STATS code could also throw light on where the problem is and so help focus your efforts. Kieran _______________________________________________ lwip-users mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/lwip-users
