From: barmar@alum.mit.edu   
      
   In article ,   
    Jorgen Grahn  wrote:   
      
   > On Mon, 2013-09-30, Les Cargill wrote:   
   > > Jorgen Grahn wrote:   
   > >> On Mon, 2013-09-30, Les Cargill wrote:   
   > >>> Is the following statement correct, incorrect or in need of amendment?   
   > >>> (You'd think you could Google for it, and you would be wrong ).   
   > >>>   
   > >>> If a TCP/IP server has a select()/recv() loop, and an error of   
   > >>> ECONRESET is ever encountered, the server *must* close the connection?   
   > >>>   
   > >>> (paraphrasing)   
   > >>> Are there transient ECONNRESET ... states in TCP/IP?   
   > >>   
   > >> That would make ECONNRESET both meaningless and mislabeled,   
   > >> wouldn't it?   
   > >>   
   > >   
   > > It *can't* be that easy. :)   
   > >   
   > >> As far as I know, ECONNRESET says the connection is irrevocably lost,   
   > >   
   > > That's what I would think, yes.   
   > >   
   > >> and there's nothing you can do about it.  And you also don't know   
   > >> exactly what the peer application's state was before the problem.   
   > >   
   > > Bingo. Neither does the developer of it...  looks like   
   > > there's UDP on my future. Just not today.   
   >   
   > UDP doesn't solve that problem, if that's what you mean. It's one of   
   > those classic problems ... does it have a name? IRTR an allegory with   
   > one general sending someone with a message to the battlefield, and not   
   > being sure the message or the reply got lost.   
      
   It's the "two generals problem".   
      
   http://en.wikipedia.org/wiki/Two_Generals'_Problem   
      
   In TCP it's an issue with orderly closes. Connection resets are even   
   worse, since they're asynchronous.   
      
   --   
   Barry Margolin   
   Arlington, MA   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)