[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [lwip-users] netconn_write blocking
From: |
Goldschmidt Simon |
Subject: |
RE: [lwip-users] netconn_write blocking |
Date: |
Wed, 10 Oct 2007 08:21:17 +0200 |
> [..]
> I realize that this probably isn't the best way to write to
> sockets, as if anything blocks, it stops sending data to all
> of the sockets.
You can get problems this way, of course, but nevertheless, it should
work... Until a client stops responding.
> This is what I'm pretty sure is currently
> happening with netconn_write
>
> Ok, next, this is what I get for my debug output when i have
> the following in my lwipopts.h ...
> #define DBG_MIN_LEVEL DBG_LEVEL_SERIOUS
> #define DBG_TYPES_ON ( API_LIB_DEBUG |\
> API_MSG_DEBUG | \
> )
> #define API_LIB_DEBUG LWIP_DBG_ON
> #define API_MSG_DEBUG LWIP_DBG_ON
>
> Debug Output:
> ( I added the LWIP:\t to each line)
> ...
> LWIP: tcp_write(pcb=0x207e78, data=0x20574c, len=18, copy=1)
> LWIP: tcp_enqueue(pcb=0x207e78, arg=0x20574c, len=18, flags=0, co
> LWIP: tcp_enqueue: queuelen: 32
> LWIP: tcp_enqueue: too long queue 32 (max 32)
Oh, THAT queue! That's something different, of course! :-) There are two
defines in opt.h to limit the amount of data being enqueued in one
tcp_pcb:
- TCP_SND_BUF: sender buffer space in bytes
- TCP_SND_QUEUELEN: number of pbufs allowed in the sender buffer
In your case, TCP_SND_QUEUELEN seems to be defined to 32, and 32 pbufs
have
already been enqueued. If you do all your writes using 18 bytes, you
will
have (18 bytes * 32 pbufs) 576 bytes in the queue, maybe that's a
problem
for the nagle algorithm or something else?
In any case, you should try to increase TCP_SND_QUEUELEN and see what
happens!
> Will netconn_write block until it can write the next segment
> in the queue?
Yes.
>
> Ok, now the good news....
> By setting the following:
>
> #define TCP_MAXRTX 4
> #define TCP_SYNMAXRTX 4
> #define TCP_TMR_INTERVAL 100
>
> I was able to cut the amount of time for a timeout down to
> like ~20 seconds. This isn't great, as all of the other
> connections will be without data for that ~20 seconds, and
And that's the bad news! A better solution (which is not yet
implemented)
is to use send timeouts (like we have receive timeouts already).
But as I said, it remains a todo for lwIP...
> also, it seems like I'm setting the number of times the
> packet can be retransmitted pretty low. But once the
> connection timed out, netconn_write returns, and the netconn
> is deleted, and everything continues to operate normally.
>
> This is at best a flimsy fix, so if anyone has better ideas,
> please feel free to send them my way.
Yes: increase TCP_SND_QUEUELEN and if it still locks up, use wireshark
to see what's
happening and post the packet trace here if you have questions about it!
Simon