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