lkml.org 
[lkml]   [2001]   [Jun]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectState changes for T/TCP
Date
Hi everyone,

I am trying to implement T/TCP in linux 2.2.14. I am using a Linux box as a
client and a FreeBSD box as server. I have the following problem:

I send multiple data packets from the client, the sequence looks like this:

1. Client sends syn with data <SYN, PSH>
2. Client sends data <PSH>
3. Client sends data along with its fin <FIN, PSH>
4. Server sends synack <SYN, ACK>
....................................
5. Server sends his data and finishes <FIN, PSH, ACK>
6. Client acks the data <ACK>
7. Server sends fin again <FIN, ACK>
8. Client sends reset <RST>

My problem is in segment 8. In segment 5 the client is already in FIN_WAIT2
since the server acked his fin (client's fin in segment 3) in previous
segments (shown with dots), and when he gets the fin from the server he acks
(segment 6) it and gets in TIME_WAIT (tcp_time_wait() in 2.2.14). But in
tcp_time_wait() the original socket gets linked to another socket-like
structure and then gets closed (CLOSE). Now, when the segment 7 arrives it is
dropped by the client (since its socket is in CLOSE state) and a RST is send
back. But what should happen in T/TCP is that in segment 8 i should have an
ACK for the FIN in segment 7.
My question now (provided that all that i have mentioned before are correct)
is: Should i change the above behaviour of original TCP? If i leave the
socket in TIME_WAIT instead of CLOSE, would that require further changes?

Thank you all in advance
Tasos

p.s. please CC your e-mail to my address (anpol@intracom.gr)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 12:55    [W:0.024 / U:0.100 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site