> Once upon a time Andreas Krueger shaped the electrons to say...
> >is there a way to accounting the transfered bytes of a session?
>
> With recent ComOS releases input and output octects are reported to
> RADIUS Accounting.
Provided they don't overflow. Suppose a person with a 28.8 transfers
3,000 bytes per second and is continually downloading from Redhat's site
;-). Two overflow the 32 bits of the Input-Octets attribute requires
about 1400000 seconds, which is a little over two weeks.
Move up to ISDN and transfer rates of 8000 bytes/sec and it is less than a
week.
So, if your niche is the consumer market, and you have policies that you
enforce that prevent long, high-traffic connections, you are safe from
overflow.
If you mostly want to know the traffic to make cool graphs or for other
statistical reasons, you can safely ignore the overflow since it is rare.
If, on the other hand, you sell 24x7 accounts to businesses, some of which
have huge amounts of traffic and you want to bill them for that traffic,
the overflow becomes very serious. We have many dozens of customers who
stay connected for over a week at a time, and many that are connected over
a month. Overflow would mean losing a GB of traffic, which is an awful
lot if you are metering MBs.
That is why I have been trying to propose extensions to RADIUS accounting
to make it more reliable for billing long-term connections. So far I
have seen alot of private "That's a great idea, let's make a new protocol"
type responces. I have also seen alot of "No extensions to RADIUS other
than XYZ is allowed." I have not seen any discussion of the
merits/weaknesses of my proposal, or attempts to think through how the
issue can best be addressed within the RADIUS protocol.
----------------------------------------------------------------------------
Steven P. Crain scrain@shore.net http://www.shore.net/~scrain
Shore.Net Unix Development and Administration
An ISP with Excellence in the Greater Boston Area.