RE: [lwip-users] tcp_enqueue problem, using socket:

[Bill Auerbach]

> If you are using the sockets interface, you don't have to worry about the
> calls to tcp_write. They are internal to the stack operation.

In any case, his problem will result by the socket interface calling it.

> Instead what seems to be happening is correct and expected behaviour when
> your remote end is not acking the data fast enough so it's buffering up
> locally waiting to be sent.

He's seeing what I was dealing with 2 weeks ago and I (respectfully) agree
that this is a problem that can (and should) be avoided.  The error is that
you can stay below tcp_sndbuf() amount of data for tcp_write (regardless of
who calls it) and exceed TCP_SND_QUEUELEN causing an error (and now, as
Piero adds, with Nagle enabled).  If you reach either tcp_sndbuf data or
TCP_SND_QUEUELEN segments, the system should block (with possibly tcp_sndbuf
should return 0 to indicate the connection really cannot accept any more
data).

> If you are trying to send data quickly from
> your application then this would be normal since you can usually send more
> data faster than it can be sent over the wire.

It's normal, but would be throttled by tcp_sndbuf indicating there is no
room, in which case tcp_sent would continue to ask for data as it can be
accepted.

The following might be a good idea, to be used before calling tcp_write:

#define tcp_accept_data(pcb) ((pcb)->snd_buf > 0 * (((pcb)->queuelen <
TCP_SND_QUEUELEN))

This gives you the amount of data the connection can accept which will be 0
if TCP_SND_QUEUELEN is reached.

> If data throughput is slow,
> then you may want to look at the wire to find out how quickly data is
> being acked to see if there's a problem at either end.
> 
> So your application would be blocked sometimes. lwIP's sockets layer
> currently implements non-blocking behaviour with O_NONBLOCK for reads, but
> not for writes.

Doesn't it block when tcp_sndbuf is full?  If so, this error can occur
before that time.

Bill