[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: |
Nick Brereton |
Subject: |
Re: [lwip-users] Non-blocking netconn callback and TCP accept backlog |
Date: |
Tue, 17 Jul 2012 09:39:28 +0100 |
> -----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