[SNMP4J] Response for original request after first retransmission discarded

[Frank Fock]

Hi Jones,

Well described observation. Yes, SNMP4J 1.x behaves
that way. I have checked the SNMPv3 RFC 3412 and
I think it allows to optimize the behavior
to allow receiving a response to a former retry
(or original request) after the next retry has
been send out.

I will now implement that optimization for
SNMP4J 2.0. Depending on the implementation
complexity, I will also provide a back-port
for the 1.x branch.

Best regards,
Frank

On 19.07.2011 14:25, jones vinu wrote:
> Hi Frank,
>
> We have a case in snmpv3 request where we receive a response for the first request after we have send the first retries. Our timeout for the first request is 8 sec we receive the response after 8 sec for this request hence we discard this message(msgID could not be found in the log). Is this an excepted behavior or the response after the first retries still be processed?
>
> Debug log
>
> Sending first request
> 2011-07-18 16:39:21,879 DEBUG [186]-[org.snmp4j.mp.MPv3] Adding cache entry: StateReference[msgID=1307970872,pduHandle=PduHandle[1225850246],securityEngineID=80:00:02:7d:03:00:0e:86:1c:12:17,securityModel=org.snmp4j.security.USM at 6dff17b9,securityName=gpon123,securityLevel=3,contextEngineID=80:00:02:7d:03:00:0e:86:1c:12:17,contextName=nt]
>
> Sending first retries after 8 sec
>
> 2011-07-18 16:39:29,885 DEBUG [Timer-17]-[org.snmp4j.mp.MPv3] Adding cache entry: StateReference[msgID=1307970884,pduHandle=PduHandle[1225850246],securityEngineID=80:00:02:7d:03:00:0e:86:1c:12:17,securityModel=org.snmp4j.security.USM at 6dff17b9,securityName=gpon123,securityLevel=3,contextEngineID=80:00:02:7d:03:00:0e:86:1c:12:17,contextName=nt]
> 2011-07-18 16:39:29,994 DEBUG [Timer-17]-[org.snmp4j.security.USM] getUser(engineID=80:00:02:7d:03:00:0e:86:1c:12:17, securityName=gpon123)
>
> Response for first request. We get the response after the second retry so the cache is overridden with the first retry msg. PDUHandle is the key in the map and the retries use the same PDU handle for all retries. This explains the msgID could not be found in the cache and the NoError warnings.
>
> 2011-07-18 16:39:31,560 DEBUG [DefaultUDPTransportMapping_192.168.5.12/0]-[org.snmp4j.mp.MPv3] SNMPv3 header decoded: msgId=1307970872, msgMaxSize=65535, msgFlags=07, secModel=3
> 2011-07-18 16:39:31,561 DEBUG [DefaultUDPTransportMapping_192.168.5.12/0]-[org.snmp4j.security.USM] getUser(engineID=80:00:02:7d:03:00:0e:86:1c:12:17, securityName=gpon123)
> 2011-07-18 16:39:31,562 DEBUG [DefaultUDPTransportMapping_192.168.5.12/0]-[org.snmp4j.mp.MPv3] RFC3412 §7.2.10 - Received PDU (msgID=1307970872) is a response or internal class message, but cached information for the msgID could not be found
> 2011-07-18 16:39:31,562 WARN  [DefaultUDPTransportMapping_192.168.5.12/0]-[org.snmp4j.MessageDispatcherImpl] noError
>
> Thanks
> Jones
> _______________________________________________
> SNMP4J mailing list
> SNMP4J at agentpp.org
> http://lists.agentpp.org/mailman/listinfo/snmp4j

-- 
AGENT++
http://www.agentpp.com
http://www.snmp4j.com
http://www.mibexplorer.com
http://www.mibdesigner.com