[AGENT++] VACM 3.5.13 problem

[Marek Malowidzki]

> In fact, the agent does not block. Simply, our embedded hardware is so
slow
> that it remains blocked for about 1 minute or longer while we make GETBULK
> requests to non-available (due to VACM masks) subtrees. Looks like there
is
> significant overhead related to access checks. On faster hardware, the
delay
> is almost unnoticeable.

Well, so it works ok. The problems we encountered with VACM where incorrect
errors were returned for unavailable (through VACM settings) tables were
present in 3.5.13 but disappeared in 3.5.14.

However, the implementation still seems to be quite slow. For example, on
our embedded system, it is much faster to retrieve data (e.g., a complete
ifName column, about 70 entries) using GetNext in a 10Mbit LAN (with full
access to the whole agent's MIB) than to get endOfMibView (when a user has
only access to the IP MIB). This seems a bit surprising, since the first
operation requires 70 messages to be exchanged in both direction and the
second requires a single call. This is with logs enabled, which may add some
overhead. Nonetheless, access checks seem to be really expensive.

Marek

BTW. I noticed the following in the Pdu class (pdu.h):

void set_notify_id(const Oid id) { notify_id = id; };
should't it be const Oid& ?