Re: detect bytes written on abort

>TCP is a reliable transport, meaning that at the application layer, one
>always know exactly how much data the client received, and this is
>always equal to how much was successfully sent.

The above is *NOT* a conventional definition of "reliable transport".
And it's not what TCP tries to implement.

Stdio buffering put on a "reliable transport" as you define it above
makes it unreliable, as a successful fwrite() on a socket may simply
mean that the data has been placed in a buffer on the sender, not
even passed to the OS yet. You also don't know how much data is
buffered by Apache or web proxies. You don't know that the other
end of the TCP connection is on the user's browser.

In a scenario where the communication channel is going to be cut
at some point in time (corresponding to, say, a modem dropping
carrier or network connectivity otherwise going down and staying
down), and no further message traffic is possible, it is impossible
to implement a protocol where the sender and receiver always agree
exactly on the number of bytes received. If you send a packet and
get no answer, you don't know whether the sent packet got lost or
the acknowledgement got lost. You can get the uncertainty down to
one byte by sending single-byte packets all the time. Slow. Wasteful
of bandwidth. Even the Theory of Relativity is relevant here. The
Speed of Data, as well as the Speed of Light, is finite and does
not permit instantaneous communication of information.

>I don't care how many
>bytes were transferred by TCP in the data link layer.

>I don't want to restart sending the file. I also do not care why the
>script aborted.

You DO care if the *client* aborted. Just because the browser got the
data from TCP doesn't mean it was safely saved to disk before someone
tripped over the power cord.

>Of course, it must be from a network/client abort, not
>a server reboot or such, because the script must finish executing. I
>only want to be able to track how many bytes were sent to the client,
>which equals the value that is eventually written to the server log file.
>
>The reason I need it is because in this system, I want to be able to
>show the user how many bytes the server sent them. This will tell them
>how much data transfer they have used.

Why would the user care? Unless you're billing them against a quota
or something, which is quite a different problem from being able
to restart a file transfer.

>I need the status of bytes sent as soon as possible after the script
>completes or aborts. Thanks.

It won't happen reliably. You might get something accurate enough
for *quotas*, but not for restarting file transfers. The way things
like FTP do this is get the size of the partially-transferred file
on the client side and start from there.

Gordon L. Burditt
.

Relevant Pages

  • Re: detect bytes written on abort
    ... makes it unreliable, as a successful fwrite() on a socket may simply mean that the data has been placed in a buffer on the sender, not even passed to the OS yet. ... You don't know that the other end of the TCP connection is on the user's browser. ... to implement a protocol where the sender and receiver always agree ... I only want to be able to track how many bytes were sent to the client, which equals the value that is eventually written to the server log file. ...
    (comp.lang.php)
  • Re: FTP Error 426
    ... TCP also provides a means to communicate to the receiver of data that at some point further along in the data stream than the receiver is currently reading there is urgent data. ... correct description is "command" not "subcommand", specifically an "FTP service command", see section 4.1.3. ...
    (bit.listserv.ibm-main)
  • Re: Making sure you receive it all
    ... TCP connection represents a stream. ... Microsoft MVP, MCSD ... at the receiver the size in network byte order... ...
    (microsoft.public.win32.programmer.networks)
  • Re: Problem with writing fast UDP server
    ... it likely means you have reached your ethernet bandwidth ... frames) to achieve your desired results. ... Keep in mind TCP is stream based, not datagram based so you may need ... On your client, make the following changes. ...
    (comp.lang.python)
  • Re: Log Out Issues
    ... UDP is the way to go for internet games. ... Apparently the extra overhead in TCP can cause a lot more lag in your game, ... >> Lets say the client sends a log out request to the server reliably. ...
    (microsoft.public.win32.programmer.networks)