yep, indeed a good idea!
On Thu, Oct 8, 2009 at 12:47 AM, Yann Suisini <[email protected]>wrote: > > Maybe a good idea could be have the same feature when sending data : > a ->recv_timeout field , either 0 for blocking or another valuer when you > want a timeout on a sent packet but non acknowledged (or an unsent packet > due to memory or other error). > > This way we could choss for a fully blocking or non blockin netconn ! :-) > > Yann. > > > > DownyTif wrote: > > > > ok, maybe I posted my question a little early. I figured it out and it's > > working fine. For the record, here is what I did: > > 1- Changed LWIP_SO_RCVTIMEO to '1'; > > 2- Since I want to "netconn_accept()" call to be blocking, I did this, > > where > > pNetConnListener is a struct netconn*: > > > > // Put a timeout of 0 to force a blocking accept. > > pNetConnListener->recv_timeout = 0; > > pNetConnListenerNewConn = netconn_accept(pNetConnListener); > > > > 3- Since I want a non-blocking "netconn_recv()", I did this: > > > > // Check for incoming frames. > > pNetConnListenerNewConn->recv_timeout = receiveTimeoutInMs; > > pNetBuffer = netconn_recv(pNetConnListenerNewConn); > > if (pNetBuffer != NULL) > > { > > ....... > > } > > else > > { > > // Detect if there was a problem or it's because there was no data. > > if (pNetConnListenerNewConn->err == ERR_TIMEOUT) > > { > > // No data received. Since we should receive a keep alive packet > > every x seconds, > > // this mean that the host has a problem or the connection has > > been > > broken > > // (disconnected cable for example). Disconnect and prepare for > > next > > connection. > > break; > > } > > else > > { > > // For any other errors, it's a problem. Disconnect and prepare > > for > > next connection. > > //print_dbg("CommManager - ListenerTask Connection > Problem.\n\r"); > > break; > > } > > } > > > > My search of LWIP_SO_RCVTIMEO indicated that it's not used anywhere else > > that needs attention (except for the netconn_accept()). So, now I can > > disconnect and reconnect my cable at will! > > > > Hope this helps some others! > > > > > > > > > > On Fri, Oct 2, 2009 at 11:44 AM, Dany Thiffeault > > <[email protected]>wrote: > > > >> Hey, > >> I was testing the stability of my system, so I disconnected the Ethernet > >> cable from my lwIP device and reconnected it. I found out that the > >> connection wasn't re-initializing itself. I foudn out that my task is > >> blocked in netconn_recv() indefinatly. > >> > >> I absolutly need to be able to detect a network fault and go back into > >> connection accepting state. I searched around and found threads about > >> this > >> exact question, but the replies were all: swith to raw API. > >> > >> This is not good for me, since I'm using a multi-task system with RTOS, > >> sequential API. > >> > >> My LWIP_SO_RCVTIMEO is 0 currently, and according to the code, it looks > >> like I could put this to 1 and not block. But I just want to use it on > >> the netconn_recv() > >> call, no others... > >> > >> Any advice here? Is it the way to go? > >> Thanks! > >> > > > > _______________________________________________ > > lwip-users mailing list > > [email protected] > > http://lists.nongnu.org/mailman/listinfo/lwip-users > > > > -- > View this message in context: > http://www.nabble.com/Possible-to-have-netconn_recv-unblocking--tp25718024p25798712.html > Sent from the lwip-users mailing list archive at Nabble.com. > > > > _______________________________________________ > lwip-users mailing list > [email protected] > http://lists.nongnu.org/mailman/listinfo/lwip-users >
_______________________________________________ lwip-users mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/lwip-users
