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

[Jonathan Larmour]

Piero 74 wrote:
> J,
> is there a solution to prevent this block? or, as Bill said, lwip 
> doesn't do any test, and gives this problem if my application will call 
> a lot of time tcp_write with small pieces?

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.

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

Jifl

> 2008/3/18, Jonathan Larmour <address@hidden 
> <mailto:address@hidden>>:
>
>     Piero 74 wrote:
>      > Hi.
>      >
>      > i'm using socket on lwip 130rc1.
>      >
>      > i have this problem:
>      >
>      > after some send operation, in tcp_enqueue, here:
>      >
>      >   /* If total number of pbufs on the unsent/unacked queues
>     exceeds the
>      >    * configured maximum, return an error */
>      >   queuelen = pcb->snd_queuelen;
>      >   /* check for configured max queuelen and possible overflow */
>      >   if ((queuelen >= TCP_SND_QUEUELEN) || (queuelen >
>      > TCP_SNDQUEUELEN_OVERFLOW)) {
>      >     LWIP_DEBUGF(TCP_OUTPUT_DEBUG | 3, ("tcp_enqueue: too long queue
>      > %"U16_F" (max %"U16_F")\n", queuelen, TCP_SND_QUEUELEN));
>      >     TCP_STATS_INC(tcp.memerr);
>      >     pcb->flags |= TF_NAGLEMEMERR;
>      >     return ERR_MEM;
>      >   }
>      >
>      > my code loop forever, in this piece of code, with queuelen =
>      > TCP_SND_QUEUELEN, without send any packet, incremeting err in
>     tcp.memerr
>
>
>     Since I assume your thread is blocked in the send, lwip is trying by
>     itself
>     to resend the data. You can see how it does this in api_msg.c. The
>     sent_tcp
>       function is called when TCP data is really sent. More will be sent
>     if it
>     needs to be from sent_tcp by calling do_writemore (or indeed, that's
>     how it
>     will know that all data in the write has finished). The send buffers are
>     also periodically topped up if they need to be by using the poll_tcp
>     callback, which also calls do_writemore. This is called from the tcp
>     slow
>     timer every 500ms.
>
>     This will be why you are seeing that code called lots of times.
>     Sometimes
>     it won't get ERR_MEM, or at least it shouldn't. Unless the
>     connection has
>     really stalled because the remote end has stopped acking packets.
>
>     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
>
>
>     _______________________________________________
>     lwip-users mailing list
>     address@hidden <mailto:address@hidden>
>     http://lists.nongnu.org/mailman/listinfo/lwip-users
>
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> lwip-users mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/lwip-users


--
eCosCentric Limited      http://www.eCosCentric.com/     The eCos experts
Barnwell House, Barnwell Drive, Cambridge, UK.       Tel: +44 1223 245571
Registered in England and Wales: Reg No 4422071.
------["The best things in life aren't things."]------      Opinions==mine