Does Accept event happen after the three way handshake?
Asked Answered
W

3

5

I am writing an application on Linux (Client and Server) with socket programming. I came across the scenario, where my server application never responds to the initial SYN packet of the other end.

I am still debugging the issue.

Since my server is listening on a port, it never generates the accept event. Is the accept event is generated after the TCP handshake is done OR the accept event is generated when the initial SYN packet is received?

Some useful links would be helpful.

Wira answered 26/8, 2013 at 19:20 Comment(3)
Maybe your listen backlog fills up?Martz
What is the specific behavior you are seeing and what is your question about that behavior?Dareece
@xaxxon.. I am not finding any accept events generated, eventhough the tcpdump shows that SYN packet reached the server on that specific port.My question is: Is accept event not generated because the handshake is not over ?Wira
M
9

Since my server is listening on a port, it never generates the accept event.

That doesn't make sense. If your server is listening it should generate the accept event.

Is the accept event is generated after the TCP handshake is done

Yes.

OR the accept event is generated when the initial SYN packet is received?

No. The handshake has already happened. accept() just delivers you a socket from a queue of already accepted connections. While the queue is empty, it blocks. And the accept event (really a 'readable' event on the listening socket) is generated whenever that queue (the listen() backlog queue) has something in it.

This means that a client can connect even if the server has never called accept().

Masakomasan answered 26/8, 2013 at 22:34 Comment(1)
@Zephyr Rubbish. Your citation doesn't say any such thing. Read it again.Masakomasan
K
2

Accept() is not exactly an event, but a function that encapsulates the server side logic for the TCP handshake. The function is called beforehand(waiting for a client connection) and it returns after the handshake is over (it received the ACK from the client).

Some detailed explanations here: http://lwn.net/Articles/508865/ http://www.ibm.com/developerworks/aix/library/au-tcpsystemcalls/

What kind of error do you get? Make sure your server is reachable for the client.

Kirkpatrick answered 26/8, 2013 at 20:12 Comment(5)
If you are using select() and passing the server's fd, then accept() would be triggered as a read-event.Prink
Manoj, wouldn't this mean that select() completed the three way handshake and that therefore the client thinks its connected when, in fact, it should wait for an explicit "accept" from the server? In other words, wouldn't this make "accept" redundant?Kirkpatrick
@ManojPandey is correct. Your comment doesn't make sense. Neither accept() nor select() 'completes the handshake'. TCP does that, in the kernel. Your answer doesn't convey that, and it fails to convey the possibility that the handshake has already happened before accept() is called.Masakomasan
The server maintains a list of established connection in a queue and when the application calls accept(), the underlying layer dequeues the connection and returns that file descriptor to the application. So, when the accept() call returns an fd, the 3-way hand-shake has already been done for that fd.Prink
Thanks all.. that clarified my doubt.Wira
B
0

The TCP handshake is handled by the kernel; the server process is not involved. The kernel maintains two queues, one for incomplete connections (initial SYN received) and one for complete connections (3-way handshake complete).

The accept call retrieves the first entry in the complete queue, if the queue is empty and the socket is blocking the call blocks until a connection is made. If the socket is nonblocking, the call fails with EAGAIN or EWOULDBLOCK.

refs:

  1. https://books.google.com/books?id=ptSC4LpwGA0C&lpg=PP1&pg=PA104#v=onepage&q&f=false/0131411551_ch04lev1sec5.html
  2. https://man7.org/linux/man-pages/man2/accept.2.html
Bambi answered 8/7, 2020 at 17:54 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.