[AGENT++] Asynchronous interface in SNMP++

[Marek Malowidzki]

> > Summarizing: I think that the synchronous threads should not execute
> > callbacks. Callbacks should be executed by threads that explicitly enter
> > event processing loop, e.g. calling something like
> > snmp.eventListHolder->SNMPProcessEvents().
>
> Of course this would be better. It would require an additional queue
> where responses are stored that just wait for the call of the callback.
>

Thank you for the response. I really appreciate your help (and the effort
involved in SNMP++). Of course, I realize that the code has a long history
and was created a long time ago so still one has to face some "legacy"
design decisions. Anyway, I personally consider SNMP++ sufficiently elegant
to use it without a pain ;-).

The implementation of an event list is quite complex - I know because it
have implemented it myself ;-) (for another purpose). For example, some SNMP
toolkits do not support calling multiple requests on the same Snmp session
object (there is a strict request-response coupling), which simplifies the
implementation a lot (but also places constraints on a client code).
Especially when v3 is in use.

One more question: the Pdu class models all possible Pdu types (Request,
Response, Trap, etc.) and contains a sum of all possible fields. Why does
not it hold nonRepeaters and maxRepetitions for GetBulk? A user has to
provide these values for Snmp::get_bulk() but it would be more consistent to
add such properties to the Pdu class (otherwise response() should have
contained parameters for setting error status and index, etc.). To complete
this thread, I would also add that it would be helpful for a user to have
static factory methods for creation of Pdu of the required type (e.g.,
Snmp::create_response(const Vb* vbs, int error_status, int error_index),
etc.). This would enable to make sure that all required fields for a given
Pdu type have been initialized.

By the way, I have implemented the asynchronous interface for my SNMP++.NET
component and it seems to be a lot faster than the synchronous one. I was
doing tests on a local SNMP agent; walking the system branch using the
asynchronous interface is at least 2.5 times faster than using the
synchronous one (that is, e.g. for 5 synchronous threads and 5 asynchronous
"activities", run in parallel, I get significantly less than 100
requests/second for the synchronous case and nearly 250 requests/second for
the asychronous one). The huge difference would suggest that the synchronous
threads are waiting actively (that is, from time to time they perform some
action), otherwise it is difficult to explain so big difference. My first
guess is that in SNMPProcessEvents(), multiple threads are blocked on
select() and then all of them are released to enter
SNMPProcessPendingEvents() and then to check if the event they are waiting
for has arrived. So, in fact, all the threads are looping and - in the
current design - the have to loop to check when their message arrives. Which
may cause significant overhead if there is high activity (multiple
threads/messages received from a socket).

I believe that fixing this behavior would not be that difficult (do not
press you to do it immediately, just theoretizing ;-) ) - the threads should
be waiting on a semaphore/event type object untill the event processing
thread wakes them up (and no more need to walk the list of events) or the
timeout expires. The event list could be replaced with a hashtable indexed
with the request_id. Etc. Under this model, I would expect the difference in
performance to be a lot smaller (say 10%).

Best regards,

Marek