Linux-Kernel Archive: Re: RFC: per-socket statistics on receive Re: RFC: per-socket statistics on received/dropped packets From: Stephen Hemminger (shemminger@osdl.org) Date: Fri Jun 14 2002 - 10:51:15 EST Next message: Benjamin LaHaise: "Re: [PATCH] 2.5.21 IDE 91" Previous message: Stephen Rothwell: "Re: [PATCH] make file leases work as they should" In reply to: Lincoln Dale: "Re: RFC: per-socket statistics on received/dropped packets" Next in thread: Ben Greear: "Re: RFC: per-socket statistics on received/dropped packets" Reply: Ben Greear: "Re: RFC: per-socket statistics on received/dropped packets" Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] 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/ Next message: Benjamin LaHaise: "Re: [PATCH] 2.5.21 IDE 91" Previous message: Stephen Rothwell: "Re: [PATCH] make file leases work as they should" In reply to: Lincoln Dale: "Re: RFC: per-socket statistics on received/dropped packets" Next in thread: Ben Greear: "Re: RFC: per-socket statistics on received/dropped packets" Reply: Ben Greear: "Re: RFC: per-socket statistics on received/dropped packets" Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] This archive was generated by hypermail 2b29 : Sat Jun 15 2002 - 22:00:31 EST
