Skip to content
This repository has been archived by the owner on Mar 8, 2022. It is now read-only.

Implement GetBulkRequest and a getSubtree function which utilises it. #44

Open
wants to merge 8 commits into
base: master
Choose a base branch
from

Conversation

bangert
Copy link
Collaborator

@bangert bangert commented Nov 15, 2016

Requesting feedback for this implementation of GetBulkRequest.


// Helper to check whether `oid` in inside the tree rooted at
// `root` or not.
var inTree = function (root, oid) {
Copy link
Owner

@calmh calmh Nov 23, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why the move and reindent of this function?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

because inTree() now is used by both the pre-existing getSubtree() and the new getSubtreeBulk().

// max-repetitions is the number of next variables that should be fetched
pkt.pdu.error = 0;
pkt.pdu.errorIndex = options.max_repetitions;
pkt.pdu.type = 5;
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This should probably be a constant instead

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

it wasnt in getNext(). Would you want me to change both?

Copy link
Owner

@calmh calmh left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks quite reasonable to me. Is it tested? :)

@bangert
Copy link
Collaborator Author

bangert commented Nov 23, 2016

Unfortunately I have not written formal tests for this - but we use it and it doesn't seem to fail against our switches (50+ device types).

Perhaps we should discuss whether or not we even want a getSubtreeBulk - or perhaps the current getSubtreeBulk should replace the existing getSubtree. Is it justified to have both implementations?

@calmh
Copy link
Owner

calmh commented Nov 25, 2016

There should probably be only one getSubtree, that uses the best available method. If there are no compatibility issues with always using getBulk we should probably do that? if we expect issues, perhaps there could/should be a flag to fall back to normal getNext etc?

@bangert
Copy link
Collaborator Author

bangert commented Dec 13, 2016

OK - let me see when i find time to get this into shape.

@bangert
Copy link
Collaborator Author

bangert commented Jan 25, 2017

I think this is it.

@bangert bangert mentioned this pull request Jun 13, 2017
@bangert
Copy link
Collaborator Author

bangert commented Jun 13, 2017

in the pas few weeks i have developed a healthy portion of skepticism, that just having one getSubtree is the way to move forward. perhaps i should redo this with a getBulkSubtree as there is equipment out there that may not support getbulkrequest...

the lack of test for the getbulkrequest is also still a problem.

@calmh
Copy link
Owner

calmh commented Jun 13, 2017

So, eh, I'd obviously forgotten all about this (sorry!). I'm fine with either. Probably I'd suggest going with this as the one and only getSubTree, and when it becomes a clear issue that there is equipment that doesn't support this that we should work with - (re)introduce a getSubtreeCrappily that does it without bulk...

@bangert
Copy link
Collaborator Author

bangert commented Jun 14, 2017

i actually have equipment, which has a configuration variable which allows to enable bulk requests. so my getSubtree did not work until i enabled bulk requests in the configuration of the device.

wrt tests, snmpjs does not support getBulkRequest, so all the getSubtree tests now fail. I am not sure what a good way forward is here...

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants