Subject: Re: REMOPS MIB Indexing

From: Randy Presuhn <[email-masked]>
Date: Fri, 26 Mar 1999 11:00:48 -0800 (PST)

Hi -

> Date: Thu, 25 Mar 1999 15:59:25 -0500
> To: [email-masked]
> From: Bob Stewart <[email-masked]>
> Subject: Re: REMOPS MIB Indexing
...
> Are applications required to use the spin lock value as an index?  If so,

no.

> how is that enforced?  If not, the spin lock is of marginal value.

no.  It provides a simple way to reduce the probability of collisions.

> Applications will still need code to handle collisions where they try to
> create an entry that's already been created.

This happens if there are other command generators with the same group
permissions that are not using the TestAndIncr object.  Sure, a robust
application needs to deal with the possibility.  I'd like to keep the
"normal" case streamlined.

> Note that using the spin lock will suggest numbers that are unique across
> all owners, which isn't necessary, while having a spin lock per row is
> rather overdoing it.

The draft does not state, assume, or require that the numbers would be
unique.  It's just a harmless side-effect of the way TestAndIncr works.
I'd be worried only if there were a requirement for more that 2^32-1
entries to be active concurrently.

> Overall, if an arbitrary integer is to be used it's generally best either
> to suggest that applications use a random number or to supply a "next
> index" per row that applications can read first.

Why would the "next index" need to be per row?

I don't put much faith in "random" number selection.  In particular, the
same failure mode (network drops response to a set request that failed
due to row collision) exists as with TestAndIncr, but the failure is
more likely to occur, since the "random" approach will see collisions
even if all implementations are polite, but the TestAndIncr approach
encounters collisions only if there are implementations that ignore the
TestAndIncr object AND happen to select the same value.

> No matter what you do, good applications must code for the possibility of a
> collision and retry the suggested number selection algorithm if they get one.

Absolutely.

> I'd prefer the random number approach.

See above.

> Actually, I'd prefer just biting the bullet and letting people name their
> test entries with a text string.  That way they can supply whatever sorting
> or site-specific content seems appropriate to them, and have a meaningful
> identification that people can remember and use or even predict.  That's
> the direction we've been going in other MIBs.
...

The value of using names for things depends in part on what their lifetimes
are.  If these entries were persistant, names would make a great deal of
sense.  How long do you envision these entries lasting?

 -----------------------------------------------------------------------
 Randy Presuhn           [email-masked]     http://www.bmc.com
 Voice: +1 408 616-3100  BMC Software, Inc.           965 Stewart Drive
 Fax:   +1 408 616-3101  Sunnyvale, California 94086  USA
 -----------------------------------------------------------------------
 Any relationship between my opinions and BMC's is coincidental.
 -----------------------------------------------------------------------