MibProxy based on table index

[Chris Paulsen]

Ok....

I talked too soon.

I got things working by modifying my derived class further so that on the 
first pass through for a new sub-agent (responsible for a set of rows)  the 
first oid in the get next request is set to the oid (base of the sub-tree) 
of the proxy.

This seems to work fine, but I still need to ensure that this is 
threadsafe. Is the thread safety of the lastNext VB assured by the fact 
that each sub-request is processed on its own thread with a snapshot of 
MibProxy class at the point the thread is started? If so then this should 
also apply to my values...

Is there any thought to adding proxy by row abilities to the MibProxy 
class? I know this is something that Sun's SEA package provides. Maybe they 
added this instead of support for SNMPv2c or v3...;-)

Thanks for enduring my ramblings.


- Chris



At 05:21 PM 10/25/00 -0500, Chris Paulsen wrote:
>Frank:
>
>
>My class derived from MibProxy is forwarding get requests just fine, but I 
>am still having trouble with get-next requests.
>
>The problem is that I successfully traverse the first row from the first 
>agent, but then only pick up the last column of the second agent because I 
>am looking for the successor of the last element of the first row.
>
>To illustrate an example of my traversal is below followed by a question:
>Agent to contact is determined by first index.
>
><base>.<column>.<index 1>.<index 2>
>--------------------- source 1 -------------------------------
><base>.2.1.1
><base>.3.1.1
><base>.4.1.1
>------------------------------------------------------------------
>
>--------------------- source 2 -------------------------------
><base>.4.2.1
>------------------------------------------------------------------
>
>
>My question is:
>What is calling find_succ in my derived class and setting the input 
>parameter id (the Oid to find the successor of)? I need to reset this 
>input parameter for this function so that each sub-agent contacted is 
>passed the same value for the first get-next request. I have tried setting 
>the oid and value of lastNext to no avail.
>
>I hope this makes sense. Any suggestions would be appreciated.
>
>
>thanks,
>    Chris
>
>
>
>
>
>Agent to contact is determined by first index.
>
><base>.<column>.<index 1>.<index 2>
>--------------------- source 1 -------------------------------
><base>.2.1.1
><base>.3.1.1
><base>.4.1.1
>------------------------------------------------------------------
>
>--------------------- source 2 -------------------------------
><base>.4.2.1
>------------------------------------------------------------------
>
>
>I have overriden find_succ in my derived class so that it changes the 
>source after the first row/agent has been p
>
>
>At 07:04 PM 10/24/00 +0200, Frank Fock wrote:
>>Chris Paulsen wrote:
>>
>> > I'm trying to develop a  variant of the sample proxy agent for v1 and v2c
>> > agents that goes to a different sub-agent based on the index into a table.
>> > Only get and get-next requests are allowed on the sub-agents. Each 
>> subagent
>> > would be bound to provide certain rows from the table. Is this possible?
>> >
>>
>>Yes, if you can determine the subagent to ask by the index only.
>>
>> >
>> > If anyone has any suggestions as to what MibProxy methods I would need to
>> > override I would be very grateful?
>>
>>The method you mentioned below will do it.
>>
>> >
>> > I was thinking of the following:
>> >
>> > 1. Derive class from MibProxy which takes additional parameters in the
>> > constructor consisting of a map of the index portion of Oid and the
>> > corresponding source.
>> >
>>
>>OK.
>>
>> >
>> > 2. Override get_request and find_succ so that they set the internal
>> > 'source' for the MibProxy objects to the one specific for a given index.
>> > Call the base class (MibProxy) methods get_request and find_succ from the
>> > derived class.
>>
>>Good idea, but be careful with GETNEXT requests. How do you
>>handle the transition from one subagent to the other? That may be
>>difficult, depending on how the indexes can be distinguished.
>>
>> >
>> > Does this sound like it should work and make sense? Does anyone have a 
>> more
>> > elegant idea?
>>
>>It does.
>>
>>Best regards,
>>Frank
>>
>>--
>>Frank Fock - AGENT++
>>Email: frank at fock.de
>>Fax: +49 7195 177108
>
>------------------------------------
>Christopher Paulsen
>Datalex
>(formerly Sight & Sound Software)
>------------------------------------
>cpaulsen at sight-n-sound.com
>Voice: 503.445.4271
>Fax: 503.274.0939

------------------------------------
Christopher Paulsen
Datalex
(formerly Sight & Sound Software)
------------------------------------
cpaulsen at sight-n-sound.com
Voice: 503.445.4271
Fax: 503.274.0939