From: rick.jones2@hp.com   
      
   glen herrmannsfeldt  wrote:   
   > Actually two questions.   
      
   > (If you don't understand the specifics, you might not want to think   
   > about the answers.)   
      
   > First: In the case of sending a large e-mail message, if the TCP   
   > connection is interrupted before it is finished, is the message sure   
   > not to be sent?  I believe so, but if it goes through as EOF to the   
   > SMTP server, it seems that it might send an incomplete message.   
   > Specfically a very large video file.   
      
   > Second: Again assuming a very large file, and with the addition that   
   > it is being sent through a cellular modem over many minutes, is it   
   > possible that the client progress bar could reach "SENDING MESSAGE:   
   > 100% COMPLETE" even though the message was incomplete?  Consider the   
   > case of a cell tower being destroyed during transmission.   
      
   > In the case of a small message, I can see that it might fit into one   
   > buffer, that buffer be passed to TCP, and considered sent.  (It   
   > seems that many ftp clients do that in timing a file transfer.)   
      
   > In the specific case, it is at least multiple seconds, which should   
   > be long enough that there would still be buffers to fill.   
      
   > (also, this is not homework)   
      
   Although neither of them are TCP questions.  Rather they are questions   
   about the behaviour of applications/protocols using TCP.  I suspect   
   that the first question would be covered by the SMTP specification(s).   
   The second question is one for the author(s) of the mail user agent   
   (MUA) using the cellular modem.   
      
   Now, backing up from the questions themselves.  If an application is   
   simply dumping data into a socket associated with a TCP connection,   
   there can be as much as SO_SNDBUF data queued to the socket that is   
   not yet at the remote.  Similarly, there can be as much as SO_RCVBUF   
   data queued at the receiving TCP which has not been recvieved by the   
   remote application.   
      
   If the client application then calls close().  It is telling the local   
   TCP it will be sending no more data, and expects to receive no more   
   data.  Unless the application manipulates SO_LINGER, upon return from   
   the close() call, all it knows is that TCP has been asked to send the   
   data, and the application has said it does not need/care to know if it   
   got there.   
      
   When an application wants to know the data "got there" it will have an   
   application level ACK of some form.  A common one would be for the   
   client to call shutdown(SHUT_WR) on the socket rather than close,   
   expecting then a confirmation message from the remote that it had   
   received all the data.  That might be an explicit message, or it might   
   be implicit in the remote also calling shutdown(SHUT_WR) or even   
   close() to trigger a recv return of zero - which is the "signal" an   
   applcation gets from a TCP endpoint upon receiving a FINished from the   
   other side.   
      
   Thus the reason your questions aren't really TCP questions, rather   
   application, higher layer protocol questions, because "it depends" on   
   what the application(s)/protocols are doing with TCP :)   
      
   rick jones   
   --   
   The glass is neither half-empty nor half-full. The glass has a leak.   
   The real question is "Can it be patched?"   
   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)