delegation and blocked transactions

Hi,
	Problem: our agent is in the middle between an SNMP Manager and
another software block. We don't get to redesign either of those. In one
particular use case, the manager sends a GET request, and we delegate
that to the other software block. But, in order for the other block to
give us the information needed to finish the GET transaction, we depend
on a series of SETs from the manager, and they will always come after
the GET is initiated. This results in a deadlock situation, where
net-snmp agent needs to send out the GET response before processing the
SETs, but the software block needs the SETs to be processed before it
will answer the GET.

	I realize this net-snmp behavior is by design, and for good
reasons. But, I need to find a workaround for it...

	Interested in any suggestions, back doors included. Is it
possible to map certain OIDs to a different session (but sharing the
same endpoints)? And if so, would the sessions behave independently, so
that the presence of an outstanding GET in one session not inhibit the
completion of the SETs in a different session?

	The solutions we're looking at right now are pretty ugly. I
guess if the session notion doesn't work out, we're looking for the best
way to fool net-snmp into thinking the request has been answered (we
know one way to do this already, and it's definitely a backdoor), and
then, when the needed info is available, send a copy of the original GET
request back to net-snmp for us to handle in a non-delegated fashion.

	Oh, we're using 5.3.1.

Thanks
Peter

-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone

_______________________________________________
Net-snmp-users mailing list
[email protected]
Please see the following page to unsubscribe or change other options:
https://lists.sourceforge.net/lists/listinfo/net-snmp-users