From: grahn+nntp@snipabacken.se   
      
   On Tue, 25 Aug 2009 13:10:03 -0500, Tom Einertson    
   wrote:   
   > "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.   
   ...   
      
   > 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.   
      
   ...   
      
   > 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.   
      
   That's a neat and elegant solution! I'll keep it in mind.   
      
   But right now I'm proceeding according to my previous posting. It   
   doesn't help that (a) I cannot change the log receiver much, it has   
   other clients, and (b) the protocol is actually semi-binary and starts   
   each log message with a length field.   
      
   I believe the "delayed log message" problem will be rare(*), and   
   acceptable for my use. The messages will contain a time stamp, so at   
   least the log file will not lie about when the log message was   
   generated.   
      
   /Jorgen   
      
   (*) Unless I decrease the socket buffer sizes on purpose, to   
       get the rate limitation to kick in earlier.   
      
   --   
     // Jorgen Grahn    O  o   .   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)