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 <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>>:
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
[email protected] <mailto:[email protected]>
http://lists.nongnu.org/mailman/listinfo/lwip-users
------------------------------------------------------------------------
_______________________________________________
lwip-users mailing list
[email protected]
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
_______________________________________________
lwip-users mailing list
[email protected]
http://lists.nongnu.org/mailman/listinfo/lwip-users
