James Carlson wrote:
Darren Reed writes:
I can imagine at least three different intended semantics for this
ioctl when used with TCP:
1. It reports all unsent data.
2. It reports all unsent and unacknowledged data.
I've come across people who think they want (1) for the purpose
of being able to bill on the number of bytes they've sent from their
application.
So, if their system has sent something, but the network itself eats it
or my browser crashes before I get to see it, then I still have to pay
for it.
Yes.
That sounds like somewhat less than a completely scrupulous business
practice to me.
It's not for us to judge business practice, nor is it related to
Solaris networking.
It's debatable whether or not they really want (2) but they didn't
want (3).
To address their problem, we recommended they use a dtrace script
to monitor how much data was discarded when the socket was closed.
Or just make an estimate. Any reasonable guess is bound to be as
accurate as attempting to measure data that the remote application
likely hasn't even read yet.
But they don't want to do that.
It's not our position to tell them how to write their billing.
(And if they're not comfortable feeding guesses into a billing system,
then I'd question the original strategy attempted ...)
What it turned out they were mostly interested in is "is it likely
that the other end received all of the web page data?"
If you're using HTTP, there is no ACK returned by the client
to say "I got the entire page", so using an ioctl like this is what
some people turn to in order to get that information.
Darren
_______________________________________________
networking-discuss mailing list
[email protected]
