Re: Single GET request sending multiple requests

Vinod Patil <[email protected]>
Newsgroups gmane.network.net-snmp.user
Message-ID <CAKtV5GYVVnYKn1BXFN-RRuNzj0FE5xPsQWMPQ76oFjUx+U2hbQ@mail.gmail.com>
Thanks for the response and the explanation.

On Wed 11 Jul, 2018, 02:47 Robert Story, <[email protected]> wrote:

> On Tue, 10 Jul 2018 17:13:26 +0530 Vinod wrote:
> VP> [... ] We have used the mib2c.mfd.conf (container cached) to
> VP> generate the code. [...] Also, we set the cache timeout to 0.
>
> If you don't want caching, you can regenerate the code without it.
>
> VP> Basically, we would like the table_load to load only the
> VP> requested column every time a GET request comes in instead of
> VP> loading all the columns - Is this achievable with the
> VP> mib2c.mfd.conf generated code?
>
> Not without having to delve into the depths of the guts of the
> library. If you modify the *Table_interface file, in the
> object_lookup function, you can use the request values passed in to
> set a flag in the rowreq_ctx (similar to column_set_flags) for
> columns that are actually in the get request. Then in the row_prep
> function, you only have to populate the requested columns.
>
> I'd strongly advise against try this optimization for get-next
> requests, but it should be pretty safe to do for get requests.
>
> You will have to use internal apis that aren't really meant to be
> used, and they likely aren't well documented, so expect to spend
> lots of time in a debugger to figure out exactly how things work.
>
> Robert
>

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot

_______________________________________________
Net-snmp-users mailing list
[email protected]
Please see the following page to unsubscribe or change other options:
https://lists.sourceforge.net/lists/listinfo/net-snmp-users
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.