Re: [lwip-users] Non-blocking netconn callback and TCP accept backlog

[Nick Brereton]

> -----Original Message-----
> From: address@hidden
> [mailto:address@hidden
> On Behalf Of address@hidden
> Sent: 15 July 2012 11:30
> To: Mailing list for lwIP users
> Subject: Re: [lwip-users] Non-blocking netconn callback and TCP accept
> backlog
> 
> Nick Brereton wrote:
> > 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 think it's rather different and the handshake is completed directly before
> the 'accept' callback is called. That would mean the client can send data even
> while you have enqueued the new connection. I haven't really worked that
> way, though. I also don't know how other socket implementations handle
> this...
> 
> Simon

Thank-you, I've eventually found an adequate solution -- partly I was running 
out of PBUFs in my pool, I hadn't realised that my accepted connections 
wouldn't inherit the non-blocking behaviour of the listening socket (but do 
inherit the call-back) and I was able to significantly speed up my replies by 
completely filling the current tcp window and forcing an immediate ack from the 
client. Between these, message processing is speed up sufficiently to be 
generally avoid the problems I had been seeing.

As far as I have been able to tell immediate completion of the handshake after 
it starts seems to be normal according to the listen(2) man page. However, if 
it was easy to implement a delayed handshake for lwIP it might be a useful 
option as a way to manage traffic on restricted system.

Nick