Date: 17 Aug 2001 11:03:07 +0300 From: "Adrian Pavlykevych" <pam@polynet.lviv.ua> To: freebsd-isp@freebsd.org Subject: Re: RADIUS Accounting with SQUID Message-ID: <20010817110307.F528@polynet.lviv.ua> In-Reply-To: <20010816163108.A19902@jake.akitanet.co.uk>; from paul@akita.co.uk on Thu, Aug 16, 2001 at 04:31:08PM %2B0100 References: <997919908.1446.1202.camel@localhost> <20010815094331.B12922@jake.akitanet.co.uk> <997984620.1446.2253.camel@localhost> <20010816141325.C19104@jake.akitanet.co.uk> <20010816175859.E528@polynet.lviv.ua> <20010816163108.A19902@jake.akitanet.co.uk>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Aug 16, 2001 at 04:31:08PM +0100, Paul Robinson wrote: > On Aug 16, Adrian Pavlykevych <pam@polynet.lviv.ua> wrote: > > Ummm... RADIUS really wasn't meant for that sort of (ab)use. You're going to > get a lot of UDP traffic flying over your network if you do this, but if you > think you can scale it OK - so that you generate several hundred bytes of > UDP traffic on _every_single_ HTTP request - then good luck to you. I would agree with you, if that was a cause where Internet bandwidth is comparative to local network capacity. But in such case there is no reason for very rigorous bandwidth tracking - some more coarse bandwith limiting methods could be implemented. On other hand, when Internet bandwith is scarce (or _very_ expensive like bidirectional satelite feeds), one can easily add overhead of 20-30 percent of outgoing Internet traffic to the local network which has at least magnitude larger capacity. > I think the point I was trying to make seems to have skipped well over your > head on this one - I know HTTP and Squid has no long sessions - that's my > point. That's _why_ RADIUS is probably a bad choice for this. RADIUS stands > for Remote Authentication Dial-In User Service and the name in itself tells > you what it is best at handling - 'long' user sessions that last at least a > few seconds, probably 30 or more (30seconds is a long time at this level). > You are talking about transactions that last milliseconds. I would STRONGLY > advise you read very carefully RFC2866 and maybe even preceeding RADIUS > Accounting RFCs to make sure you really know what you're doing. > > Of course, if you want to implement this, nobody is going to stop you. I > just don't think I'd want it on _my_ network... :-) I bet in first place it is economicaly unresonable to do such strict bandwith checking on _your_ network. You'd spend way more on number crunching, than save in bandwidth ;-) Your argument also applies exactly the same to any remote logging, e.g. to SQL database. If have to store per user statistics with more data, then just daily/monthly agregates, you'll have to feed data about every such transaction to the logging machine. Speaking about millisecond long transactions: if your squid cache is coping with processing user request at such pace, RADIUS server can do that easilly (it has _much_ shorter codepath and no TCP handshakes in the process). > There are other projects underway it would seem, as well, to actually handle > what you're talking about in a far easier manner through log file parsing > and the like. As to log parsers, I have personal experience with such setup. I would not call that an "easier manner". Computational expensive realtime log parsing, database reconnection logic, etc... Anyway, as in Perl "there is always more then one way to do this". Regards, -- Adrian Pavlykevych email: <pam@polynet.lviv.ua> System Administrator phone/fax: +380 (322) 742041 Lviv Polytechnic National University To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-isp" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010817110307.F528>