Duplicate requests in a session

[Peter Nixon]

On Thu 31 Aug 2006 18:19, Guy Fraser wrote:
> On Thu, 2006-08-31 at 12:31 +0300, Peter Nixon wrote:
> > Good question. Does anyone have anything against changing this?
> >
> > -Peter
> >
> > On Thu 31 Aug 2006 10:11, Santiago Balaguer García wrote:
> > > Thanks James, I don't figure out to use primary key solves the problem
> > > of duplicate keys.
> > > I had in radacct as primary key <<radacctid>> but now I am going to
> > > have <<acctuniqueid>>.
> > >
> > > This proble cause a new thread: why radacctid is the primary key of
> > > radacct table instead od acctuniqueid?
>
> I used a slightly different solution in my PostgreSQL implementation :
>
> ALTER TABLE ONLY radacct
>     ADD CONSTRAINT radacct_unique_session UNIQUE (
>         username, nasipaddress, nasportid, acctsessionid
> );

After looking at this again, a unique constraint (or primary key) 
on "acctuniqueid" will give exactly the same behaviour as you have here with 
much lower load on the database. The default acct_unique looks like this:

acct_unique {
                key = "User-Name, Acct-Session-Id, NAS-IP-Address, 
Client-IP-Address, NAS-Port"
}

Which has Client-IP-Address as well, but that is trivial to change if you want 
the same behaviour. It appears that the best way to enforce unique data in 
the database is to use the "acctuniqueid" however, the next question is:

Should we be trying to ensure unique records at runtime or should that be left 
to post processing?

I know than most people "expect" the records to be unique, but is that a 
realistic expectation? I have a pair of NAS in failover config (Rather large 
Ciscos running the absolute latest IOS technology release) which send the 
exact same values in every request:

        NAS-Port-Type = Virtual
        NAS-Port = 60000
        NAS-Port-Id = "GGSN"

Now, while this is not ideal, given that the NAS-Port-Type is Virtual it seems 
to be legal. Given that I have several thousand users all with identical 
usernames the default "acctuniqueid" is going to have exactly the same amount 
of uniqueness as the Acct-Session-Id as all other values are fixed (With the 
exception of when a NAS failover occurs).

Now in my case, I do have other things that I can add to make things more 
unique (Calling-Station-Id, 3GPP-Charging-ID, 3GPP-IMSI etc) but the point is 
that I think we are going to trade one type of problem for another. (Now we 
have people asking why their records aren't unique, later we will have 
certain sets of people asking why half their records don't appear in the 
database)

Is that a good or a bad tradeoff? I am leaning towards good, but its pretty 
close to even money..

Cheers

-- 

Peter Nixon
http://www.peternixon.net/
PGP Key: http://www.peternixon.net/public.asc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.freeradius.org/pipermail/freeradius-devel/attachments/20060901/78b92943/attachment.pgp>