From: gtaylor@tnetconsulting.net   
      
   On 3/20/20 12:43 PM, Jorgen Grahn wrote:   
   > I don't know, but it could either   
   > - discard #2 and ack #1, forcing the sender to retransmit   
   > - ack #0, but keep #2 around in case #1 shows up   
      
   There is also an option to ack #0 and #2 while waiting for #1.  This is   
   called Selective ACKnowledgement, a.k.a. SACK.  Contemporary TCP/IP   
   stacks implement SACK.   
      
   > I suspect the latter happens.   
      
   Yes, that's largely correct when SACK is not used.   
      
   > "Forever" sounded like a bad thing, but I don't think it is.   
      
   Yes, "forever" /is/ a bad thing.   
      
   What if I send you packets #2, #3, #4, #5, #6, #7, #8, #9, #10, #11,   
   #12, #13, #14, #15, #16, #17, #18, … #3,985, … #1,234,567,890.   
      
   Do you still want to hold onto the billion packets that I've sent you?   
   Probably not.   
      
   This is a form of Denial of Service (DoS).  Hence one of the reasons why   
   you want to NOT hold onto the out of order packets /forever/.   
      
   > If the local application is alive, if it hasn't requested any timeouts,   
   > if it doesn't tell the socket to die, and if there's no explicit   
   > evidence that the other side is dead, then the socket should be kept.   
      
   A socket is not the same thing as a packet.  The socket can be kept open   
   even while dropping packets.   
      
   > Even if you're without network for a week.   
      
   That's all the more reason to not keep all packets.  DoS protection.   
      
      
      
   --   
   Grant. . . .   
   unix || die   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)