Simultaneous connect, close

[junhyeok-yoon]

In the handshake-simultaneousConnect case,
As far as I know, both sides start connecting at the same time. Consider that one side sends SYN and receives SYN. Then, the connection will be established. And it will be the same to the other side.

1. However, when I see the solution packet log, there are also ACKs which are response to the SYN. Should I ignore it?

2. I cannot infer why second SYN packet of below log has peculiar SEQ#
   

3. After established, app can close, so it can send FINACK how should I response with the FINACK? I wonder how should I serve ack# and seq# of ACK packets.

4. What I want to know is HOW to handle the seq# and ack# after the connection established.

5. In handshae-before/after accept, the order of FINACKs, ACKs
   Before: FINACK ACK FINACK ACK
   After: FINACK FINAXK ACK ACK
   Each of the case is normal close and simultaneous close respectively? Also, I cannot understand how ack#, and seq# are manipulated.
   (3~5번 질문 모두 seq#와 ack#에 대한 것입니다. 기존의 정상적인 handshake이라면 syn을 보내면서 seq#를 램덤으로 설정하고 synack을 보내면서 상대방의 seq#를 정합니다. 하지만 simultaneous connect을 하면 Syn을 보나면서 seq#를 랜덤하게 설정하는데, 또 그 뒤에 synack을 받기 때문에 이경우에는 최초 설정한 seq#를 유지해야하는건지 아님 어떻게 해야하는지 궁금합니다.)

[Pusnow]

For SEQ# and ACK# for simultaneous connection see:

KENSv3/Documentation/rfc/rfc793.txt

Lines 2075 to 2093 in eba97b6

	TCP A TCP B
	1. CLOSED CLOSED
	2. SYN-SENT --> <SEQ=100><CTL=SYN> ...
	3. SYN-RECEIVED <-- <SEQ=300><CTL=SYN> <-- SYN-SENT
	4. ... <SEQ=100><CTL=SYN> --> SYN-RECEIVED
	5. SYN-RECEIVED --> <SEQ=100><ACK=301><CTL=SYN,ACK> ...
	6. ESTABLISHED <-- <SEQ=300><ACK=101><CTL=SYN,ACK> <-- SYN-RECEIVED
	7. ... <SEQ=101><ACK=301><CTL=ACK> --> ESTABLISHED
	Simultaneous Connection Synchronization
	Figure 8.

1. However, when I see the solution packet log, there are also ACKs which are response to the SYN. Should I ignore it?

It seems a bug in the reference TCP implementation. You can ignore it.

2. I cannot infer why second SYN packet of below log has peculiar SEQ#

The SEQ# is randomly assigned for security. It is a common practice in the real TCP networking stacks.

3. After established, app can close, so it can send FINACK how should I response with the FINACK? I wonder how should I serve ack# and seq# of ACK packets.

The FIN packets increase SEQ# by 1.

See:

KENSv3/Documentation/rfc/rfc793.txt

Lines 2484 to 2526 in eba97b6

	TCP A TCP B
	1. ESTABLISHED ESTABLISHED
	2. (Close)
	FIN-WAIT-1 --> <SEQ=100><ACK=300><CTL=FIN,ACK> --> CLOSE-WAIT
	3. FIN-WAIT-2 <-- <SEQ=300><ACK=101><CTL=ACK> <-- CLOSE-WAIT
	4. (Close)
	TIME-WAIT <-- <SEQ=300><ACK=101><CTL=FIN,ACK> <-- LAST-ACK
	5. TIME-WAIT --> <SEQ=101><ACK=301><CTL=ACK> --> CLOSED
	6. (2 MSL)
	CLOSED
	Normal Close Sequence
	Figure 13.
	TCP A TCP B
	1. ESTABLISHED ESTABLISHED
	2. (Close) (Close)
	FIN-WAIT-1 --> <SEQ=100><ACK=300><CTL=FIN,ACK> ... FIN-WAIT-1
	<-- <SEQ=300><ACK=100><CTL=FIN,ACK> <--
	... <SEQ=100><ACK=300><CTL=FIN,ACK> -->
	3. CLOSING --> <SEQ=101><ACK=301><CTL=ACK> ... CLOSING
	<-- <SEQ=301><ACK=101><CTL=ACK> <--
	... <SEQ=101><ACK=301><CTL=ACK> -->
	4. TIME-WAIT TIME-WAIT
	(2 MSL) (2 MSL)
	CLOSED CLOSED
	Simultaneous Close Sequence
	Figure 14.

4. What I want to know is HOW to handle the seq# and ack# after the connection established.

I cannot understand what are you asking. If you meant how to decide SEQ# and ACK#, read:

KENSv3/Documentation/rfc/rfc793.txt

Line 1597 in eba97b6

3.3. Sequence Numbers

5. In handshae-before/after accept, the order of FINACKs, ACKs
   Before: FINACK ACK FINACK ACK
   After: FINACK FINAXK ACK ACK
   Each of the case is normal close and simultaneous close respectively? Also, I cannot understand > how ack#, and seq# are manipulated.

BeforeAccept is normal close, and AfterAccept is simultaneous close.

(3~5번 질문 모두 seq#와 ack#에 대한 것입니다. 기존의 정상적인 handshake이라면 syn을 보내면서 seq#를 램덤으로 설정하고 synack을 보내면서 상대방의 seq#를 정합니다. 하지만 simultaneous connect을 하면 Syn을 보나면서 seq#를 랜덤하게 설정하는데, 또 그 뒤에 synack을 받기 때문에 이경우에는 최초 설정한 seq#를 유지해야하는건지 아님 어떻게 해야하는지 궁금합니다.)

Since you have received SYN before sending SYN/ACK, you have already know peer's SEQ#, so you can use it to decide ACK#.

[junhyeok-yoon]

Thank you so much!