|
|
Posted by Gordon Burditt on 01/09/06 04:04
>> 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.
Yes.
And remember, it is impossible for the end sending the file to tell
whether a packet it sent, or the ack for it, got dropped. Either
way, it looks just the same. There's always one packet full of
uncertainity, no matter what you do to the protocol. And one byte
packets are horribly inefficient.
>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.
*HOW* would this "become an issue"? Please explain *WHY* you want
to bill the way you have said you want to.
Someone needs to get better networking facilities so the problem
of aborted file transfers doesn't happen so often?
Experiment some time with this. Download something, then pull the
network cable or phone cable. Look at the difference in bytes saved
vs. what you recorded as bytes sent. Is it consistent (sort of)?
Perhaps you could approximate things with "if it failed, charge
bytes sent minus X".
>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?
Unless you're charging, and people are actually PAYING, more than
$5 a *byte* for this stuff, I think you have a completely overblown
idea of how much your data is worth. Perhaps you ought to be
delivering it by limousine accompanied by armed thugs who collect
payment before turning over the data.
>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?
Yes. Nobody would do it if you didn't blab on the net that this
was how you were charging. To be practical, someone would have to
arrange for their TCP stack to do it only on PARTICULAR connections
as doing it on all of them would really screw up trying to do
anything on the net. (But I can see how such a hack would be
possible, perhaps with a custom ioctl() call to turn on such wierd
treatment.)
Now, why is your data worth going to that effort to steal? You can
also keep counts of failed and successful transfers, and someone
trying the same 5 MB file repeatedly will probably stick out like
a sore thumb in the statistics. Then you look closer and maybe
shut off the account.
You cannot request a range of bytes with TCP. You can with HTTP, but
I think that requires using headers that PHP can see and refuse to
deliver if you're worried about this. And the simplest way to deal
with this is to charge by the byte SENT. Then there's no incentive to
do that. In fact, there's an incentive to make connections work
reliably the first time.
A lot of people handle this by selling a particular file, at which
time the customer is charged for it, and he then gets as many tries
as he wants to download the file over the next few days (or perhaps
forever). There usually isn't much reason to keep downloading the
file over and over (unless they are having trouble), since it doesn't
get updated. The user has to log in, and posting his username/password
on the internet can be detected by massive use from all over.
Gordon L. Burditt
Navigation:
[Reply to this message]
|