|
|
Posted by Shailesh Humbad on 01/07/06 06:26
Gordon Burditt wrote:
>>> 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
Okay, I think I see what you're saying. The "write" actually writes
first into internal buffers of the operating system, and so the number
of bytes it returns is not necessarily the number of bytes delivered.
"Write" only blocks if the internal buffers are full. So the number of
bytes returned by "write" (or "send") is the number of bytes written
into the TCP stack, but not the number of bytes that received ACKS
indicating delivery.
In any case, an extra 32-64K of bandwidth used on failed connections is
acceptable. I'll have to figure out a way to prevent this from becoming
an issue.
Question, could someone take advantage of this by writing a network
driver that requests data, but then doesn't send ACK replies after the
initial request is completed? My server's TCP stack would happily send
out 32-64KB of data, waiting for the ACKs. The nefarious recipient
would receive and save this data, drop the connection, and then request
the next range of bytes. Then, they would be able to download the data
without it registering as bandwidth-used on my server. Is this possible?
Navigation:
[Reply to this message]
|