I believe these statements to be true, mostly from reading RFC 791:   
      
   1) You may put data in the SYN and SYN+ACK segments, but it doesn't make any   
   sense since the TCP connection isn't established yet.   
      
   2) You may put data in the ACK segment which acknowledges the SYN+ACK.   
      
   3) I'm not sure if the ACK acknowledging the SYN+ACK can carry the FIN flag,   
   but I can't find any prohibition for it.   
      
   4) The TCP state diagram in RFC 791 makes it look like you can't have a FIN   
   flag in the ACK segment that acknowledges a FIN segment.  I believe this is   
   because the diagram is documented as being incomplete.   
      
   So I believe that the shortest (in segments, not bytes or time) TCP connection   
   is as follows:   
      
   Client <-> Server   
   -> SYN   
   <- ACK, SYN   
   -> ACK, data, FIN   
   <- ACK, data, FIN   
   -> ACK   
      
   On Saturday, January 19, 2013 6:10:26 PM UTC-5, glen herrmannsfeldt wrote:   
   > Jorgen Grahn  wrote:   
   >   
   > > On Sat, 2013-01-19, glen herrmannsfeldt wrote:   
   >   
   > >> Can you add data to the SYN, SYN+ACK, and ACK packets   
   > >> of the three-way handshake?   
   >   
   > >> Can you add FIN on the last (and first) data packet?   
   > >> That is, does:   
   > >> 1)  SYN+data+FIN   
   > >> 2)  SYN+ACK+data+FIN   
   > >> 3)  ACK   
   > >> work?   
   >   
   > > I asked here in 2005 or 2006.  IIRC, the answer was close to "maybe in   
   > > theory, but in practice this is broken in OSes, or disabled to avoid   
   > > attacks."  This also ties into the T/TCP protocol, and why it was   
   > > flawed and abandoned.   
   >   
   > >> Usually, I would choose UDP in this case, but some might   
   > >> like TCP better.   
   >   
   > > I'd try to avoid designing protocols with short-lived connections   
   > > in the first place!   
   >   
   > It does seem that the trend is to keep the connection open and reuse   
   > it when possible. But UDP is much easier to do in an FPGA than TCP.   
   >   
   > As I understand it, the receiver isn't supposed to get the data until   
   > after the ACK, in which case it wouldn't (usually) have data to return.   
   > (That is where a UDP server could respond based on a UDP request.)   
   >   
   > After that post, I got out my Comer, and was looking through the state   
   > machine diagram, but I couldn't decide if it should work or not.   
   > It might be that it isn't the full state machine.   
   >   
   > Probably it should be two separate questions.   
   > First about data on the SYN and SYN+ACK, and second on   
   > putting FIN on the SYN and SYN+ACK.   
   >   
   > -- glen   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)