From: rick.jones2@hp.com   
      
   Les Cargill  wrote:   
   > I am writing a TCP server. It is running on an embedded linux   
   > platform, not a workstation. Yes, I have full source to the kernel   
   > and all drivers.   
      
   > If the following sequence occurs, send()crashes without   
   > returning:   
      
   > Client                             Server   
   > send()   
   >                                     select()   
   >                                     recv()   
   > close()   
   >                                     send() *crashes*   
      
   > I somehow don't think it is supposed to do that.   
      
   If the timesequence is as you give it, modulo the distance between the   
   two systems, that send() call would certainly elicit a TCP RST (ReSet)   
   segment from Client.   
      
   > How can I tell the socket is closed before calling send()?   
      
   I presume you mean the *remote* socket has been closed?  That is   
   indicated locally by a read return of zero on the socket.  When Client   
   called close(), that caused TCP to send a FINished segment to Server.   
   That FIN segment is Client TCP's way of saying to Server's TCP "I am   
   sending you no more data."  Server's TCP indicates that to the   
   application by causing the recv() issued after any queued data is   
   received to return a value of 0.  What it means beyond that (eg that   
   Client expects to receive no more data) is up to the application   
   "protocol."  A FIN could have been triggered by Client calling   
   shutdown(SHUT_WR) against the socket at its end.  Thus why the   
   interpretation of the read return of zero being more than "There is no   
   more data coming" is a matter of application protocol design.   
      
   > please spare the assembled any "but it's not supposed to do that".   
   > It does; it's likely a bug and not one I will spend any time chasing   
   > if I can find a workaround.   
      
   What do you mean by send() "crashes?"  Do you mean your application   
   crashes when it makes the send() call?  Do you mean the system   
   crashes?   
      
   Even if your Server checks for and correctly interprets the read   
   return of zero before it goes to send(), there is still going to be a   
   timing window - if Server does not send what I assume is a response to   
   what I assume is a request of Client by the time Client gives-up and   
   closes the connection, there will still be the chance that Server   
   calls send() before the FIN segment from Client's close() arrives.   
      
   Thus, if doing so does indeed cause some sort of "crash" in Server you   
   will likely still have to address the crash.   
      
   One way to further close the window would be, if you control Client,   
   to have client call shutdown(SHUT_WR) and be willing to keep the   
   socket around a while, draining it, until it too receives a read   
   return of zero, indicating that Server has seen a read return of zero   
   on its end and "acknowledged" it by closing at its end.   
      
   More details are in the works of Stevens, Fenner and Rudoff and/or   
   Stallings.  Perhaps others.  Useful references to have on hand when   
   writing networked applications.   
      
   rick jones   
   --   
   I don't interest myself in "why." I think more often in terms of   
   "when," sometimes "where;" always "how much."  - Joubert   
   these opinions are mine, all mine; HP might not want them anyway... :)   
   feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)