delegation and blocked transactions

permalink · #1 (**permalink**) 05-09-2008

This is a multi-part message in MIME format.

--===============0687748957==
Content-class: urn:content-classes:message
Content-Type: multipart/alternative;
boundary="----_=_NextPart_001_01C8B213.F921D044"

This is a multi-part message in MIME format.

------_=_NextPart_001_01C8B213.F921D044
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

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

------_=_NextPart_001_01C8B213.F921D044
Content-Type: text/html;
charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
6.5.7652.24">
<TITLE>delegation and blocked transactions</TITLE>
</HEAD>
<BODY>


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


</BODY>
</HTML>
------_=_NextPart_001_01C8B213.F921D044--

--===============0687748957==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

-------------------------------------------------------------------------
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;198757...un.com/javaone
--===============0687748957==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--===============0687748957==--

Thread Tools
Show Printable Version Email this Page
Display Modes
Linear Mode Switch to Hybrid Mode Switch to Threaded Mode