[AGENT++] NoSuchInstance in case of an unavailable row within atable

Thu Jul 22 10:52:33 CEST 2004

Hi again,

Oh, yes - I've forgotten GETBULK.
Well is the difference between GETNEXT and GETBULK processing that big?
The process_get_bulk_request method does almost the same as process_request
(find successor, call get_next ...). 
Or is there anything I've to keep particulary in mind?

Other question: when do you think you'll provide the next release?
We'll do our next internal release by end of next week.
It would be very helpful for us if we can incorporate the "holes in tables"-feature until then and remove the unsecure workaround.

Regards,
Marcus

-----Original Message-----
From: Frank Fock [mailto:fock at agentpp.com] 
Sent: Donnerstag, 22. Juli 2004 09:46
To: Fehde, Marcus
Cc: agentpp at agentpp.org
Subject: Re: [AGENT++] NoSuchInstance in case of an unavailable row within atable

Hi Marcus,

I would have prefered that you overwrite the get_access() method and call the get_request of your leaf from there. But you surely have your reasons why this does not work properly.

Changing the GETNEXT processing this way will work, and I do not see any problems, except that 1. You will have the call entry->end_synch() before you jump to AGAIN. 2. You will also have to change the GETBULK processing which is more complex ;-)

Best regards,
Frank

Fehde, Marcus wrote:

>Hi Frank!
>
>I just tried my suggestion and it seems that it works.
>The modifications within process_request:
>
>case (sNMP_PDU_GETNEXT): {
>  .
>  .
>  .
>  MibEntryPtr entry;
>  Oidx tmpoid(req->get_oid(reqind));
>AGAIN:                                 <=======
>  lock_mib();
>  .
>  .
>  .
>  req->set_oid(tmpoid, reqind);
>  entry->start_synch();
>  unlock_mib();        
>  entry->get_next_request(req, reqind);
>        
>  if( req->get_value( reqind ).get_exception_status() == sNMP_SYNTAX_NOSUCHINSTANCE )
>    goto AGAIN;
>          
>  entry->end_synch();
>  .
>  .
>  .
>
>The tmpoid is moved to the next instance / successor on every loop.
>
>
>Even though it does the processing as I want it to do in my scanerio, 
>I'm absolutely not sure about the side-effects. Please can you assess 
>this modification?
>
>Regards
>Marcus
>
>-----Original Message-----
>From: agentpp-bounces at agentpp.org [mailto:agentpp-bounces at agentpp.org] 
>On Behalf Of Fehde, Marcus
>Sent: Donnerstag, 22. Juli 2004 07:11
>To: Frank Fock
>Cc: agentpp at agentpp.org
>Subject: RE: [AGENT++] NoSuchInstance in case of an unavailable row within atable
>
>
>Hi Frank,
>
>both methods of resolution are not sufficient, because the earliest 
>point where I can determine whether the instance is accessible or not is within the get_request method of the leaf.
>So if I want to skip the leaf at this late point I think I've to change the process_request method of Mib. The first part of this method does the successor search and accessibility checks, then the get-next method is called. If the call to the method does not have any result the process has to go back to the beginning and look for the next successor.
>
>How do you handle this in the row creation scenario? As far as I now a 
>newly created row that has no default values causes a noSuchInstance 
>exception. Or is the Agent++ implementation different in this point and 
>always assuming a default value (provided by the data containing in the 
>cloned leafs)?
>
>I do really hesitate to change the request processing in our agent, 
>because I'm sure that a can estimate all side effects of this change. 
>On the other hand I don't want to cancel a table traversal only because 
>of a not accessible leaf (behind this leaf might be some kind of 
>hardware as sensors, actuators, etc. that is sometimes not available 
>for any reason).
>
>Do you have any further ideas?
>
>Regards
>Marcus
>
>-----Original Message-----
>From: Frank Fock [mailto:fock at agentpp.com]
>Sent: Mittwoch, 21. Juli 2004 19:14
>To: Fehde, Marcus
>Cc: agentpp at agentpp.org
>Subject: Re: [AGENT++] NoSuchInstance in case of an unavailable row within a table
>
>
>Hi Marcus,
>
>You will have to overwrite the MibTable::find_next(const Oidx&) method 
>and return 0 if you cannot find a successor in your table. Normally you 
>would have overwritten MibEntry::find_succ(const Oidx&), but MibTable 
>is handled different than other MibEntry subclasses (for historic 
>reasons). This should/will be sort out in a future release. By 
>overwriting find_next today you will be safe in any case.
>
>If you do not want to overwrite MibTable::find_next because the 
>information you need to decide whether an instance is available or not is rather
>local to
>your MibLeafs than to the table, then you could overwrite the 
>MibLeaf::get_access()
>method too and return NOACCESS in case you want to skip it.
>
>Best regards,
>Frank
>
>Fehde, Marcus wrote:
>
>  
>
>>Hi!
>>
>>I've a table of MibTable with derived MibLeaf instances as columns. 
>>The get-method is overloaded and retrieves always the current value of 
>>something. If I can't retrieve the current value a want to return a 
>>noSuchInstance exception to mark the row or single cell as currently 
>>unavailable. I did it this way: vb.set_syntax( 
>>sNMP_SYNTAX_NOSUCHINSTANCE ) : vb was taken from request
>>
>>The problem is that the agent does not try to retrieve the next 
>>available instance, but responses the OID contained in the 
>>GETNEXT-request. The result is that my MIB browser does an endless 
>>loop. The exception is included in the response varbind.
>>
>>Can somebody tell me what the problem is?
>>
>>Best regards/Mit freundlichen Gruessen
>>
>>Marcus Fehde
>>Dipl. Ing. Technische Informatik (FH)
>>
>>Research & Development
>>Business Unit Anaesthesia
>>_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>>
>>DRÄGER MEDICAL
>>
>>Dräger Medical AG & Co. KGaA
>>Moislinger Allee 53-55
>>D-23542 Lübeck
>>
>>Tel:  + 49-451-882-3646
>>Fax: + 49-451-882-4410
>>E-mail: marcus.fehde at draeger.com
>>www.draeger-medical.com 
>>_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
>>
>>
>>
>> 
>>
>>----------------------------------------------------------------------
>>-
>>-
>>
>>_______________________________________________
>>AGENTPP mailing list
>>AGENTPP at agentpp.org http://agentpp.org/mailman/listinfo/agentpp
>> 
>>
>>    
>>
>
>
>  
>

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: InterScan_Disclaimer.txt
Url: http://lists.agentpp.org/pipermail/agentpp/attachments/20040722/9d401afe/attachment.txt 