Calling accept() and sending SYN,ACK

[David Goodenough]

I'm 99% certain I know the answer to this, but would just like to get
100% confirmation.

Is it true that a server which is listening for connections does not
send the SYN,ACK packet back to a client until after the application
actually calls accept(sock, addr, addrlen); ?

Thanks in advance,
David G.

[Casper H.S. Dik]

Incorrect. accept() won't get the connection until the 3-way handshake
is completed.

Casper
--

[Barry Margolin]

In article <4ecad96e$0$6961$e4fe...@news2.news.xs4all.nl>,

To further clarify, calling listen() is what tells the stack to start
sending SYN/ACKs. Once you do this, the stack will start accepting
connections, and queue them up, at least up to the backlog limit you
specified (but I think there are some implementations that ignore the
backlog). Accept() is how you pull these connections off the queue.

--
Barry Margolin
Arlington, MA

[David Schwartz]

On Nov 21, 1:56 pm, David Goodenough <dav...@kixeye.com> wrote:

> Is it true that a server which is listening for connections does not
> send the SYN,ACK packet back to a client until after the application
> actually calls accept(sock, addr, addrlen); ?

Theoretically, an implementation could do it either way. However,
every real-world implementation, by default, does not wait for you to
call 'accept' before it sends the SYN/ACK. This would needlessly
delays TCP session setup time and harm the platform's benchmark
scores.

The closest to an exception is Windows. Windows has a special accept
function in addition to the regular 'accept' function called
'WSAAccept'. You call this *before* even the SYN arrives to 'prime'
the accept. You can specify a pointer to a function you provide that
Windows will call to decide whether to send the SYN/ACK (and also set
QoS parameters and do other stuff).
http://msdn.microsoft.com/en-us/library/windows/desktop/ms741513%28v=vs.85%29.aspx

There is a performance hit associated with using this function.

DS