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

[Jonathan Larmour]

Bill Auerbach wrote:
 >> 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

Actually I'm not sure what he's seeing - all he said so far is that his
program is blocked when he sends data.

> 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).

I probably haven't been paying a huge amount of attention to other mails
that have been going by and maybe haven't joined the dots - I thought your
earlier problems were resolved. From your description above, I'm not quite
sure what you mean by the system blocking - at this level (Nagle, and
inside tcp_write) there should be no blocking obviously. As far as the
netconn API is concerned, further data gets sent when space is available by
calls to do_writemore in the sent_tcp() and poll_tcp() callbacks.

Can you perhaps go back to first principles and write a clear summary of
the problem - what you are seeing that is wrong (with what sorts of sizes
of writes and send buffer/queue sizes), and what you think the cause of the
problem is, since you've been analysing it. And then submit it at
<https://savannah.nongnu.org/bugs/?group=lwip>. If there's a problem with
our Nagle implementation we may well want to resolve it before 1.3.0 is
released, so we need to track this issue. It either wants fixing, or at
least understanding it.

>> 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.

Sure.

> 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.

What do you see as the advantage of doing this before calling tcp_write, as
opposed to at present where the check is made inside tcp_write and ERR_MEM
returned?

>> 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.

Sorry yes true.

Piero will have to give more details of his config (and symptoms!) to
ascertain what is really going on here. What I was trying to say was that
from what Piero was describing, what is going on may be normal expected
behaviour.

Jifl
-- 
eCosCentric Limited      http://www.eCosCentric.com/     The eCos experts
 **  Visit us at ESC Silicon Valley <http://www.embedded.com/esc/sv>  **
 **  April 15-17 2008, Booth 3012, San Jose McEnery Convention Center **
Barnwell House, Barnwell Drive, Cambridge, UK.       Tel: +44 1223 245571
Registered in England and Wales: Reg No 4422071.
------["Si fractum non sit, noli id reficere"]------       Opinions==mine