Posted by Peter Fox on 10/03/17 11:36

Following on from Shailesh Humbad's message. . .

8><

>
>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. To solve
>the file restart problem, I can implement HTTP range handling later.
>
>"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

Gordon, being the sort of person who spots the cracks down which bad
things happen that most people miss, is suggesting that what you sent
will not be the same as what was received unless completed and there
will be buffers of various sorts between your code and your cable to the
Internet and then some. In this he is trying to be helpful because the
effort required to engineer a byte-accurate solution is going to be a
great deal more than to obtain an estimate.

Here is a 'free' solution: If a file transfer fails then charge for
half the full size. Either there are very few failures in practice in
which case the issue is not very important in the scheme of things; or
it happens all the time, in which case this will work out fine
statistically. [But you will lose all your customers for reasons of crap
service.]


--
PETER FOX Not the same since the bolt company screwed up
peterfox@eminent.demon.co.uk.not.this.bit.no.html
2 Tees Close, Witham, Essex.
Gravity beer in Essex <http://www.eminent.demon.co.uk>

[Back to original message]