RE: [lwip-users] netconn_write blocking

[Goldschmidt Simon]

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