On Sat, Mar 7, 2015 at 4:39 PM, Thomas Besemer <thomas.bese...@gmail.com>
wrote:
>
>
> On Fri, Mar 6, 2015 at 10:39 AM, Bill Fenner <fen...@gmail.com> wrote:
>
>> On Thu, Mar 5, 2015 at 1:39 PM, Thomas Besemer <thomas.bese...@gmail.com>
>> wrote:
>>
>>>
>>>
>>> On Thu, Mar 5, 2015 at 7:37 AM, Bill Fenner <fen...@gmail.com> wrote:
>>>
>>>> On Wed, Mar 4, 2015 at 11:51 AM, Thomas Besemer <
>>>> thomas.bese...@gmail.com> wrote:
>>>>
>>>>> I am working with net-snmp 5.7.3, and will be using several Sub-Agents
>>>>> in my project, with fairly large amounts of data. I have noted that
>>>>> issuing a 'snmpbulkwalk' to Master Agent results in this broken down into
>>>>> GETNEXT requests to the Sub-Agent. This results in a lot of network
>>>>> traffic, as well as a tremendous number of context switches (everything
>>>>> running on same host).
>>>>>
>>>>> Is there support in the Sub-Agent to accept GETBULK requests from the
>>>>> Master? I have looked at the code, their appears to be some
>>>>> infrastructure
>>>>> in place, but it is not clear to me if it is fully functional.
>>>>>
>>>>
>>>>> More so, is there a means to configure the Master to send GETBULK
>>>>> requests to the Sub-Agent?
>>>>>
>>>>
>>>> This is something that I've been working on a little. Both of these
>>>> are relatively small tweaks. However, the bigger problem is that while the
>>>> subagent is processing the request, it's basically lost the scoping info
>>>> that the master agent has sent it, and so the response from the subagent
>>>> can include info from subtrees that the master didn't ask for. There's
>>>> code in the subagent to handle this for getnext, and we could do the same
>>>> for getbulk, except I was also concerned about the overhead of fetching
>>>> this data within the subagent - I wanted to find a way to retain the
>>>> scoping info while processing the request so that request processing could
>>>> be stopped.
>>>>
>>>> I'd be happy to share what I have; if you're up for hacking too maybe
>>>> we should create a branch on github?
>>>>
>>>>
>>>>
>>>
>>> Hi Bill -
>>>
>>> I'd be more than happy to work with you on this, and perhaps do a github
>>> branch so that when we get it working, we can generate a patch set for
>>> review by community.
>>>
>>> My early investigation shows that Sub-Agent Doesn't handle anything but
>>> GETNEXT, per handle_subagent_response() - perhaps this can be confirmed?
>>> I have not looked at Master side, so it seems to me part of this could be
>>> updating handle_subagent_response() to at least return some data set, if
>>> this makes sense, and then have Master send OID down in PDU, and deal with
>>> return data. I am assuming that a return packet from a GETBULK should be a
>>> complete data set?
>>>
>>
>> Yes, my changes include handle_subagent_response and code in the subagent
>> itself.
>>
>>
>>>
>>> From what I can tell, a GETBULK PDU only contains OID, so any filtering
>>> would have to be on Master side?
>>>
>>
>> The GETNEXT and GETBULK PDUs contain SearchRangeList, which scopes the
>> request. The master sends SearchRangeList for each tree that the subagent
>> supports, e.g., if you have registrations of
>>
>> x.1 - master agent
>> x.2 - subagent 1
>> x.3 - subagent 2
>> x.4 - subagent 1
>>
>> the master agent will send subagent 1 a request for x.2, scoped to [ x.2,
>> x.3 ), then will ask subagent 2, then will ask subagent 1 again about [
>> x.4, x.5 ). The problem with the current code in my branch is that
>> subagent 1 can respond with x.2.1, x.2.2, x.4.1, x.4.2. There are two
>> problems with this:
>> 1) it may be expensive for the subagent to fetch x.4.1 and x.4.2 and
>> they're not relevant
>> 2) without filtering, the master agent will get confused by this response.
>>
>> We can fix 2 by filtering it, just like we already filter getnext. I
>> haven't pursued this path yet because I wanted to also address 1.
>>
>> See https://github.com/fenner/net-snmp/tree/agentx-getbulk for my code
>> so far.
>>
>>
>> Hi Bill -
>
> I guess I am confused here; I pulled your tree, and it only shows changes
> on Master end.
>
It turned out that the subagent basically supported the AGENTX_GETBULK
message already, except for the scoping issues that I described.
>
> Thus, a "range" sent down for an OID, which GETNEXT looks like it could
> respond to by putting everything in PDU.
>
Do you mean GETBULK? GETNEXT only asks for the subsequent object for each
request.
>
> Please excuse my naivety, as I am relatively new to SNMP, and still
> sorting out what needs to be done on PDU to Sub-Agent. RFC states that a
> range can be supplied, but that range appears to be done for one OID?
>
> My test environment is based on:
>
> http://www.net-snmp.org/dev/agent/data__set_8c-example.html
>
> I have added multiple rows, it responds as I expect, either giving me all
> the data, or a sub-set. This all via GETNEXT (several transactions), and I
> want it to come back in one packet on GETBULK. Thus, my thinking is that
> PDU/Packet that comes back from Sub-Agent should have all the data I am
> looking for.
>
> If you could give me some concepts on how to fetch above example via one
> GETBULK, I can do some coding, test. In general, if you give me
> approaches, I will do what I can to implement, respond with patch sets for
> review.
>
If you run your subagent with -Ddumph_recv,dumpx_recv you should see that
you are getting a GETBULK message from the master (if your master is
running my code). However, you'll run into the scoping problems that I
described earlier.
As I mentioned, what I really want is for the agent processing loop to be
able to use the scoping info passed in. This is passed in ASN_PRIV_INCLUDE
or ASN_PRIV_EXCLUDE types, which is why the diff includes a change to
netsnmp_create_subtree_cache to copy the end oid in these types, but the
problem is that they get overwritten by the ASN_PRIV_RETRY.
If you don't mind the overhead of retrieving data from unwanted subtrees,
you can add code to discard the extra data before generating the reply,
just like the subagent does today for getnext.
(Refer to my earlier email for more examples of what I mean. I feel like
I'm just repeating myself at this point.)
Bill
------------------------------------------------------------------------------
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the
conversation now. http://goparallel.sourceforge.net/
_______________________________________________
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
