From: gah@ugcs.caltech.edu
Rick Jones wrote:
> 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.
It seems that on my system those are 0x1001 and 0x1002. Are those
the actual values, or flags for indicating the values? Why the
difference of one?
> 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.
Yes, it seems that ftp does that. For small files the time often
comes out zero, even when the link is slow.
> 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.
Acccording to another post, for SMTP you either get one or two
copies of the message, never zero.
> 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 :)
That is why I called them very specific, but yes, I agree.
thanks,
-- glen
--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)
|
