See RFC 793 p. 66 (in the original pagination). ACK packets
are allowed in SYN-SENT state; what this means is:
1) Your socket is created.
2) It sends a SYN packet to itself, and enters SYN-SENT.
3) It receives the SYN from itself and sends a SYN/ACK.
4) It receives the SYN/ACK and enters SYN-RECEIVED.
Nifty, huh? Why would anyone want to use it? Well, it's
really just a byproduct of supoporting simultaneous creation of a
single connection between peers. Here's one scenario:
1) Imagine a process that uses a single local port for both
listening and for opening outgoing connections. This is
legal TCP, and minimizes the number of ports used (FIN-WAIT
may bit you, though).
2) Now a community of these processes communicating among themselves,
tearing down connections after each exchange between a pair of
processes. Normally, an initiating process talks to the
other processes' LISTEN connection.
3) Now imagine that two of these processes tried to talk to each
other at the same time. They'd each build a connection control
block identifying the pair of sockets, but they'll receive a
plain SYN instead of a SYN/ACK as the first packet from the
remote site.
Craig Milo Rogers
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/