Re: detect bytes written on abort

Gordon Burditt wrote:
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
I don't care how much data the client actually saved, only how much was transferred. Yes, my eventual aim is to bill against a quota. 

Why do you care about getting these numbers exact?  You don't
seem to care about what is transmitted at the data link layer,
which is probably how your provider will bill YOU if your
agreement with them involves traffic-sensitive costs.

"Reliable Delivery - Once a connection has been established, TCP guarantees that data is delivered in exactly the same order it was sent, with no loss, and no duplication. If a failure prevents reliable delivery, the sender is informed.", Internetworking with TCP/IP Vol. III, p. 103

This says nothing about knowing HOW MUCH was delivered in the case
of a failure. If the session fails, you know not all of it got
delivered. You also know that they didn't get any more than you
sent. When a write() on a socket returns, you don't know that ANY
of it got delivered (yet). A failure may be reported later. Much
later. The above quote does not say "If a failure prevents reliable
delivery, the sender is informed instantaneously with an itemized
report of how much was delivered".

Gordon L. Burditt

You have good points, but I just don't need that much resolution or accuracy. The socket will time out in 30 seconds if there is a problem sending data. The bytes returned by the write call, even if known 30 seconds later, is all I need, and I know somewhere internally in PHP it is being recorded.

When socket write returns (if being called in blocking-mode), it returns the number of bytes written successfully to the socket. This is the number of bytes guaranteed to be delivered to the client's receiving socket (though the client may not have written it all to disk or other issues may have occurred). The reason why TCP can know the number of bytes sent with certainty is because every sent packet is replied to with an acknowledgment (ACK) packet.

For my purposes, this number is going to be a decent approximation of actual bandwidth used, and I realize it's not going to be exact. Thanks.

.

Relevant Pages

  • Re: synchronization control between the socket sender and socket recei
    ... receiver receiving is to use an acknowledgement scheme. ... Client Application: ... After the client received the data, different consumers use the data in ... For example, we have file 1, 2, 3, then the server send socket of data from ...
    (microsoft.public.win32.programmer.networks)
  • Re: data packet split problem in socket networking
    ... I am new with socket applications, and now trying to build a client-server ... the SAME client. ... Each packet of data has a header, which indicates to which data source this ... needed to separate the data in the receiver buffer. ...
    (microsoft.public.win32.programmer.networks)
  • Re: data packet split problem in socket networking
    ... application to use socket for data transportation. ... I found that *sometimes* the packet received at the client side is ... needed to separate the data in the receiver buffer. ...
    (microsoft.public.win32.programmer.networks)
  • Re: data packet split problem in socket networking
    ... I am new with socket applications, and now trying to build a client-server ... I found that *sometimes* the packet received at the client side is split ... needed to separate the data in the receiver buffer. ...
    (microsoft.public.win32.programmer.networks)
  • [PATCH 0/5] [RFC] AF_RXRPC socket family implementation [try #3]
    ... These patches together supply secure client-side RxRPC connectivity as a Linux ... kernel socket family. ... presentation side is left to the client. ... Each connection goes to a particular "service". ...
    (Linux-Kernel)