It sounds like what you want is socket accounting which works like
process accounting. I.e when a socket lifetime ends, put out a record
with number of packets/bytes sent/received.
On Thu, 2002-06-13 at 17:24, Lincoln Dale wrote:
> At 09:00 AM 12/06/2002 -0400, jamal wrote:
> > > > > i know of many many folk who use transaction logs from HTTP caches for
> > > > > volume-based billing.
> > > > > right now, those bills are anywhere between 10% to 25% incorrect.
> > > > >
> > > > > you call that "extremely limited"?
> > > >
> > > >Surely, you must have better ways to do accounting than this -- otherwise
> > > >you deserve to loose money.
> > >
> > > many people don't have better ways to do accounting than this.
> >
> >Then they dont care about loosing money.
> >There's nothing _more important_ to a service provider than ability to do
> >proper billing. Otherwise, they are a charity organization.
>
> on this side of the planet (Australia), just about *all* service-providers
> offer differentiated-billing baed on a volume-usage basis.
> that includes Worldcom, Telstra, Optus (SingTel), connect.com.au (AAPT).
> some of these differentiate themselves by using caching to provide faster
> access and/or mitigate the latency overhead of simplex satellite.
> this has been ongoing for many many many years now. please just accept
> that HTTP caching is almost a necessity with the pricing models in use!
>
> >There's nothing _more important_ to a service provider than ability to do
> >proper billing. Otherwise, they are a charity organization.
>
> we're almost talking about the same thing here -- and this is my point! i
> agree that is is important - hence why i've added a getsockopt() option to
> provide octet counters from the ip+tcp level!
>
> > > in the case of Squid and Linux, they're typically using it because its
> > > open-source and "free".
> >
> >I am hoping you didnt mean to say squid was only good because it has
> >these perks.
>
> not at all. they're using it because it meets their requirements.
> once again, this is not a discussion about religion or politics!
>
> > > they want to use HTTP Caching to save bandwidth (and therefore save money),
> > > but they also live in a regime of volume-based billing. (not everywhere on
> > > the planet is fixed-$/month for DSL).
> > >
> > > the unfortunate solution is to use HTTP Transaction logs, which count
> > > payload at layer-7, not payload+headers+retransmissions at layer-3.
> >
> >Look at your own employers eqpt if you want to do this right.
> >And then search around freshmeat so you dont reinvent the wheel.
>
> once again, i respectfully disagree. while there are numerous technologies
> for accounting out there (e.g. netflow), they all break down when you have
> things like HTTP Persistent connections which may share a single
> [server-side] connection with multiple [client-side] connections.
>
> >And until you prove it is worth it and useful to other people then
> >forever thats where it belongs. I now of nobody serious about billing
> >who is using sockets stats as the transaction point.
>
> you live in a country where the billing regeme is different.
>
> > > lawn-mower support sounds like a userspace application to me.
> >
> >But we need a new system call support
>
> (yes, i did take that comment as humerous before :-)).
>
> if what i was proposing involved a new system-call then i agree that there
> would be signficant pushback. what i have is a new getsockopt()
> option. ie. in reality, no worse than getsockopt(..,TCP_INFO).
>
>
> cheers,
>
> lincoln.
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sat Jun 15 2002 - 22:00:31 EST