|
|
Posted by Gordon Burditt on 10/07/14 11:36
>> 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 has absolutely nothing to do with the number of bytes received
by the other side. The write() call (*IN BLOCKING MODE*) may return
before even one packet has been assembled to be sent. The write()
call will block if you run out of buffering. If it blocks, and
then returns, it still might not have even tried to send any data
from the last dozen or so write calls prior to the one that just
returned.
>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).
It is guaranteed that that data will be delivered to the client
*EVENTUALLY* or you will *EVENTUALLY* get an error. There is no
guarantee whatever that any of that data has been delivered (or even
attempted to be sent) at the time the write() returns.
>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.
And the write() call *IN BLOCKING MODE* does not wait for such an
acknowledgement to be received. It doesn't even have to wait for
even one packet to be sent. It would be horribly inefficient if
you couldn't overlap, say, disk reads and network writes in a
single-threaded process that is sending a file down a socket, so
writes *DO NOT* wait until the client has received the data written.
Not even blocking writes.
>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.
If you're willing to put up with, say, an extra 32k or 64k sent but
not received when the modem drops carrier, you'll get a decent
approximation. If you're expecting much better than that, you won't.
Gordon L. Burditt
Navigation:
[Reply to this message]
|