> -----Original Message----- > From: [email protected] > [mailto:[email protected]] > On Behalf Of [email protected] > 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 _______________________________________________ lwip-users mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/lwip-users
