Re: [pysnmp-users] Troubles switching from hlapi synchronous bulkCmd to asyncore equivalent
Brought to you by:
elie
From: Ilya E. <il...@gl...> - 2016-09-09 00:36:51
|
Hi Graham, As for #1, the sync version has some logic in place to produce a well-formed response table from possibly excessive data served by the agent. That additional code is here: https://github.com/etingof/pysnmp/blob/master/pysnmp/hlapi/asyncore/sync/cmdgen.py#L572 <https://github.com/etingof/pysnmp/blob/master/pysnmp/hlapi/asyncore/sync/cmdgen.py#L572> To keep next/bulk command generator going, your callback function should return True. But it should do it conditionally — when, after looking into response table, your code considers the whole table it fetched, it should return False to terminate the iteration. Alternatively, you can always issue single queries (by returning False from the callback) for as long as you want more data, by initiating next/bulk iteration right from the callback or a loop. The second approach is taken in the sync version: https://github.com/etingof/pysnmp/blob/master/examples/v3arch/asyncore/manager/cmdgen/getbulk-multiple-oids-to-eom.py#L67 <https://github.com/etingof/pysnmp/blob/master/examples/v3arch/asyncore/manager/cmdgen/getbulk-multiple-oids-to-eom.py#L67> I would not recommend descending to the “native API level” as it is way more detailed and does solve neither of the issues you mention. I’d probably experiment with borrowing a piece of relevant code from the sync version and putting it into your callback to strip excessive rows and stop when table is done. If you end up isolating the above code into a reusable subroutine, I’d welcome your PR. ;) > On 23 Aug 2016, at 14:42, Graham Hudspith <gr...@ze...> wrote: > > Hi All, > > I've a python+pySNMP script querying an agent using the hlapi (synchronous) api and I want to switch it to using the hlapi.asyncore api instead. > > This is with version 4.3.2 and using bulkCmd(). > > To do this I had to move most of my code into a callback function, create a cbCtx object to pass in a dict to store the results into and then call the snmp-engine's transport dispatcher. > > I've come across two problems: > > Since the hlapi.asyncore version of bulkCmd() does not seem to support the "lexicographicMode=False" option, I now get "extra" results returned when the data in the asked-for table runs out. Sometimes this contains entries for "columns" in the table that I have *not* asked for, sometimes it contains "columns" from "rows" in the next table > My callback seems to be called only once per query, so if the table is larger than the number of rows that will fit in one response, the code does not issue a new request and my results are truncated. My callback does not return a value, but if I add a "return True" to the end, it seems to loop forever, including many, many, results from beyond the end of the asked-for table > > Are these well known problems ? > > I can't find an example in the pysnmp code (or documentation) for the hlapi.asyncore version of bulkCmd(). Is this because no-one uses it ? > > Would I be better off switching from hlapi bulkCmd() to the "Native SNMP API" version ? > > Regards, > > Graham > > -- |