home bbs files messages ]

Forums before death by AOL, social media and spammers... "We can't have nice things"

   comp.protocols.tcp-ip      TCP and IP network protocols.      14,669 messages   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]

   Message 13,921 of 14,669   
   glen herrmannsfeldt to Jorgen Grahn   
   Re: Shortest TCP session?   
   19 Jan 13 23:10:26   
   
   From: gah@ugcs.caltech.edu   
      
   Jorgen Grahn  wrote:   
   > On Sat, 2013-01-19, glen herrmannsfeldt wrote:   
   >> Someone in another newsgroup   
      
   > Who, and which one?   
      
   comp.arch.fpga   
      
   >> is trying to get especially high TCP   
   >> connection setup/teardown rates, which reminded me that I forgot   
   >> how short a TCP connection can be?   
      
   >> 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?   
      
   > Rick Jones will most likely answer, but until then:   
      
   > 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.   
      
   Yes, the OP didn't explain the details. If he is building both   
   ends, then he can make them any way he wants, including ignoring   
   attacks. He wants 1000000 connections per second over gigabit.   
      
   >> 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)   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]


(c) 1994,  bbs@darkrealms.ca