Re: Suppress / delay SYN-ACK

[Eric Dumazet <dada1@cosmosbay.com>]

On Thursday 12 October 2006 12:13, Martin Schiller wrote:
> On Thursday, October 12, 2006 10:38 AM, Eric Dumazet wrote:
> > Well, it is already possible to delay the 'third packet' of an
> > outgoing connection with a litle hack. But AFAIK not the SYNACK of
> > incoming connection. It could be cool. Maybe some new syscalls are
> > needed:
> >
> > int syn_recv(int socklisten, ...);
> > /* give to user app the SYN packet */
> > int syn_ack(int socklisten, ...);
> > /* User app has the ability to ask kernel tcp stack to :
> >     DROP this packet.
> >     REJECT the attempt
> >     ACCEPT the attempt (sending a SYN/ACK) */
>
> So, when do you mean the user-space application should run this syscalls?
> After the call to listen()?
>

Exactly like when you call accept() on a non blocking listening socket.

If your application did asked to received notification of SYN packets, it 
should be prepared to call accept() (to be notified of fully established 
connections) and/or syn_recv() (to be notified of SYN packets)

So when poll()/select()/epoll() tells your socklisten has available events, 
your application would have to call both accept() and syn_recv() in a loop to 
empty all awaiting events.

> Another problem with this solution might be, that I don't want to block the
> listening socket with the processing of one request, because there could be
> a lot of simultaneous requests.

Yes I can imagine.