From: grahn+nntp@snipabacken.se   
      
   On Mon, 2013-09-30, Les Cargill wrote:   
   > 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.   
   >   
   > I respectfully disagree. It enables the actual solution to   
   > this problem by moving the retransmission logic into app space.   
      
   What can you do with UDP which you cannot to with TCP?  You can always   
   reconnect and try to fix the situation, if the application protocol   
   provides a way.   
      
   /Jorgen   
      
   --   
     // Jorgen Grahn    O  o   .   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)