Re: Inform Response Handling When agent is in in SNMPv3 Mode.

Hi Dave,
Thanks for the reply.

       As per my understanding in the agent,  Agent should first  
receive the response and after that it should verify with the session list.
   
       First we should recive the response and after we should check the 
outstanding sessions list, i.e the for loop in the snmp_read() API 
should be after FD checking and receiving a response from the manager 
(present in _sess_read()  API),  because second time in for loop  fdset 
fails because no fd's were presently set. So first inform request will 
not be removed from session list and it will be retransmitted after timeout.



Regards,
Venki.




Dave Shield wrote:
> On 4 November 2011 06:08, Venki <[email protected]> wrote:
>   
>>     Inform response/Get or set Request will be handled as explained below in
>> SNMPv3 Mode.
>>     
>
> Are you telling us about behaviour that you have actually seen,
> or asking how the agent works?
>
>
>
>   
>>     Problem is that if multiple informs(say minimum 2) are sent and Agent
>> has not received response for the first SNMP inform request before sending
>> second inform, but after sometimes  it receives a response and and verify
>> the message id and request id, It will not match that request id
>>     
>
> Yes it will.
>
>   
>> because,
>> the latest session conatins second inform request details not the first one.
>>     
>
> What makes you think that the session structure only contains information
> about a single outstanding request?
>
> If you look at the code(e.g. at the end of the routine _sess_async_send in
> snmplib/snmp_api.c), you will see that the session contains a *list* of
> requests for which it expects a response.
>    So when the response arrives, the agent will search this list for the
> matching request, and process that.
>
> It is quite common for an SNMP application (agent or management client)
> to have more than one request outstanding, with no guarantee as to the
> order in which responses will arrive.   There's no question that the library
> needs to be able to handle this (and done for over ten years)
>
> Dave
>
>

------------------------------------------------------------------------------
RSA(R) Conference 2012
Save $700 by Nov 18
Register now
http://p.sf.net/sfu/rsa-sfdev2dev1

_______________________________________________
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