From: tome@siemens-emis.com   
      
   "Jorgen Grahn"  wrote in message   
   news:slrnh8frna.6o1.grahn+nntp@frailea.sa.invalid...   
   > Possibly a stupid questions, and I admit I haven't thought it through.   
   >   
   > Would the following make sense?   
   >   
   > Assume I do logging, similar to Unix syslog logging, over a TCP   
   > socket. The protocol is just a unidirectional stream of   
   > CRLF-terminated lines of text. Losing some of the lines is OK (and   
   > even desireable, when some error causes a storm of log messages) but   
   > losing parts of a line is not.   
   >   
   > And I do it like this on the client side:   
   >   
   > - create a TCP socket, set it non-blocking   
   > - logging the first line means a simple write() to the socket. If that   
   >  works, fine. If I get a short count, I store the remainder of the string   
   >  for the future.   
   > - if I'm supposed to log another line, I try to write this remainder   
   >  first. If that still doesn't work, I discard the new log line.   
      
   If you control the application on the receiving end, another approach   
   would be to add an additional control character to the stream which you   
   use to signal lost or incomplete messages (let's say ^D for the   
   purposes of this discussion).  So on the sending side the algorithm   
   would be to send messages until you get back EWOULDBLOCK.  Then discard   
   the rest of the message but set a flag saying that a message was lost.   
      
   The next time the send function is called, check the 'message lost'   
   flag.  If it is set, write ^D to the connection and then try to send   
   the current message.  If the write is successful, clear the 'message   
   lost' flag.   
      
   On the receiving side, read data until you find either a CRLF or a ^D.   
   If it is a CRLF, then you have a complete message and you can process   
   it.  If it is ^D, then you know you have a partial message, so discard   
   it.   
      
   > If it *does* make sense, what are the drawbacks?  I can think of two:   
   >   
   > - A partial log line doesn't get finished until the next time   
   >  the client tries to log something -- maybe hours later.   
   >   
   > - If the server is naively written to read a complete line, it may   
   >  be blocked for hours waiting for such a remainder. On the other   
   >  hand, such a server would block forever anyway, if the client host   
   >  disappeared from the network in the middle of a log line.   
      
   This solves the problem of a partial message being logged hours later   
   when the rest of the message is resent.  It also means that the   
   receiver would know that one or more messages had been lost.  The   
   receiver could keep statistics on this if you wanted, or it could even   
   log a message about "One or more messages lost" to the log file.  This   
   would notify anyone reading the log file that some messages were   
   missing at that point in the log.   
      
   --   
   Tom Einertson                              E-mail: tom.einertson@siemens.com   
   SIEMENS Power Transmission & Distribution  Phone:  (952) 607-2244   
   Energy Management & Automation Division    Fax:    (952) 607-2018   
   10900 Wayzata Boulevard, Suite 400   
   Minnetonka, MN, 55305   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)