[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [lwip-users] Non-blocking netconn callback and TCP accept backlog
From: |
Sylvain Rochet |
Subject: |
Re: [lwip-users] Non-blocking netconn callback and TCP accept backlog |
Date: |
Sat, 14 Jul 2012 18:42:57 +0200 |
User-agent: |
Mutt/1.5.21 (2010-09-15) |
Hi Nick,
On Sat, Jul 14, 2012 at 05:24:47PM +0100, Nick Brereton wrote:
>
> When I get get a NETCONN_EVT_RECVPLUS event with 0 length for the
> listening connection I add this to a queue of accept event, which I
> then drain whenever I have memory available to process the connection.
> As I have understood it data should not start flowing until I have
> accepted the connection (presumably completion of the handshake should
> be delayed until the netconn_accept call, thus preventing the client
> from sending any data?) and the connection should be sitting in the
> tcp listen queue.
I am not a lwIP API expert too but I played recently with the
non-blocking netconn API. It seems that connections are automatically
accept()ed when using the non blocking API.
This is what I did with this strange behavior:
static void telnet_tcp_callback(struct netconn *nc, enum netconn_evt
event, u16_t len) {
if(nc == telnet_tcp_listen) {
if(event == NETCONN_EVT_RCVPLUS) {
/* We must fetch the new netconn pointer in the lwIP callback,
* else we are going to receive events about an unknown session
* ... because lwIP don't wait the session to be accept()'ed
* before sending events about it.
*/
err = netconn_accept(telnet_tcp_listen, &telnet->tcp);
if(err != ERR_OK) {
return;
}
....
Of course, this can be a lwIP bug.
Sylvain
signature.asc
Description: Digital signature