Correct working flow of accept()

[JaesukLim]

I am confused about when the connection request on the queue pops.
Reading from past discussion, KENS' backlog is saving pre-handshake requests.
What I thought is,
Client SYN packet -> pushed to the queue -> send SYNACK -> receive ACK -> accept() -> pop the request
But this is actually save the established connections. Then how about following order?
Clicne SYN packet -> pushed to the queue -> accept() (block) -> pop the request -> send SYNACK -> receive ACK -> return accept() with file descriptor

[Pusnow]

For KENS, I recommend following order (flow before Linux 2.2):

Client SYN packet -> pushed to the queue -> send SYNACK -> receive ACK -> pop the request ->  accept()

Real implementations in modern OSes. You don't need to read this.

FYI, the above is not the exact flow of modern OSes.
In the real implementations, the flow goes like below:

Client SYN packet -> pushed to the queue -> send SYNACK -> receive ACK -> accept() -> pop the request 

KENSv3/Documentation/man/listen.2.txt

Lines 60 to 64 in eba97b6

	The behavior of the backlog argument on TCP sockets changed with Linux 2.2. Now it specifies the
	queue length for completely established sockets waiting to be accepted, instead of the number of in‐
	complete connection requests. The maximum length of the queue for incomplete sockets can be set us‐
	ing /proc/sys/net/ipv4/tcp_max_syn_backlog. When syncookies are enabled there is no logical maximum
	length and this setting is ignored. See tcp(7) for more information.

[JaesukLim]

Thank you for quick response!
Then the accept() is blocked only for waiting next packet when the pending queue is empty?
I still confusing with the blocking behavior of accept()

[Pusnow]

Then the accept() is blocked only for waiting next packet when the pending queue is empty?

Yes, accept() is blocked until a new connection is established if the queue is empty.