Spec is not clear how the MIBListener would handle the SNMPResponse when it comes to table OIDs.
Can somebody provide the sequence with an app querying for queryMIBs and how it gets the MIBDefinition?
Why should registerOID take leaf as boolean? Should it matter if OID is leaf or not? Can't we know if OID has .0 it is leaf?
Again, these are my assumptions on how it works -- I haven't actually implemented this, so I'm thinking this through on the fly.
1) Since a var bind list can contain any OIDs, I assume that each MIB in the var bind list is routed independently to the appropriate MIBListener. Then, the responses from the MIBListeners would be aggregated into a full SNMP response packet to be sent back to the SNMP manager that sent the request.
2) I suppose that the community name would be checked by the MIBManager before the requests are routed to MIBListeners.
3) Hmmmm...I can't think of why we should need to specify the leaf boolean rather than parsing out the ".0".
2. How this can be done? None of the diagnostics APIs have community names in them.
Why would they have SNMPRequest.SNMP_CHECK_FOR_SET_REQUEST? SNMPResponse has enough status values to convey any error.
I assume that the community name would be checked after the SNMP packet is received, but before the notifySNMPRequest is called on the MIBListener. Then the APIs don't need to expose the community name.
I don't know what purpose SNMP_CHECK_FOR_SET_REQUEST serves, given that, as you say, error codes are available for all possible errors.
I assume you are asking about how the potentially-unknown table indices are handled. I don't have an example to provide, but following the usual SNMP flow, here is how I assume it works:
The SNMPRequest var passed into the notifySNMPRequest has a request type for a get or get-next. So, if an SNMP Manager makes a get call for a table entry with a known table index, then it sends a get-request with the exact OID for the table entry The request is routed to the appropriate MIBListener, and the passed-in SNMPRequest has type SNMP_GET_REQUEST. The MIBListener responds with the SNMPResponse for that OID. That's the easy case.
On the other hand, if the SNMP Manager does not know the table index, it makes a get-next call with an appropriate OID. This OID could be the table colummn OID (in which case the first entry for that column would be returned), or it could be the OID for a known entry in the column (in which case the next entry after that one would be returned). The request is routed to the appropriate MIBListener, and the passed-in SNMPRequest has type SNMP_GET_NEXT_REQUEST. The MIBListener responds by looking at the OID in the request, and replying with the SNMPResponse pertaining to the next OID (in lexigraphical order) it has. If there is no next OID, then the SNMPResponse would contain a status value of SNMP_REQUEST_NO_SUCH_NAME. In that case, the get-next request would be re-routed to the next (in lexigraphical OID order) MIBListener. If there is no next MIBListener, then the SNMPResponse containing the SNMP_REQUEST_NO_SUCH_NAME status would be returned to the SNMP Manager that originated the request.
Is that what you had in mind?
Thanks for the reply. The doubt is cleared.
Get request might have variable bindings but the listener API has only provision for 1 OID.
How is the community name check covered?
The set API doesn't have any access parameter.
Your use of this web site or any of its content or software indicates your agreement to be bound by these Terms of Participation.
Copyright © 2015, Oracle and/or its affiliates. All rights reserved. Oracle and Java are registered trademarks of Oracle and/or its affiliates. Other names may be trademarks of their respective owners.