[SNMP4J] Timeouts and Retries behavior.
Frank Fock
fock at agentpp.com
Wed Apr 9 23:44:37 CEST 2008
Hello Varma,
The network and agent performance is decisive
for the optimal timeout/retry strategy.
With a non-default timeout model you can
further optimize the overall performance,
for example, by resending requests
with t=500ms after t/4,t/2,t instead of
after t,t,t which is the default for 3 retries.
Best regards,
Frank
varma datla wrote:
> Hello Frank,
> We are using SNMP4J 1.8.1 to query the SNMP agent and observed the following behavior with different timeouts/retries.
>
> Requesting about 20 OIDs and processing responses asynchronously using simple implementations of ResponseListener and TreeListener (for WALK) interfaces appropriately.
>
> These timeouts and retries are being set on the CommunityTarget and snmp version is set to 1.
>
> Retries Timeout(ms) Results
> -----------------------------------------------------------------
> 3 500 100%..got all expected responses.
> 2 2000 Lost some..mostly involving WALK.
> 1 5000 Lost even more responses, WALK and the rest.
>
> When observed using Wireshark, no response is being sent by the SNMP agent and I can see the expected retries and timeouts for the non-responsive OIDs.
>
> More retries with lesser timeout is giving best results. Is this an expected behavior? Or could it be a network dependent scenario?
>
> Also wondering, what would be the expected behavior if a TimeoutModel is set on the snmp instance and Timeouts/Retries are set on the Target? Which would be preferred during the communication?
>
> I appreciate your time and effort.
>
> Thanks,
> Varma.
>
>
> __________________________________________________
> Do You Yahoo!?
> Tired of spam? Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com
> _______________________________________________
> SNMP4J mailing list
> SNMP4J at agentpp.org
> http://lists.agentpp.org/mailman/listinfo/snmp4j
--
AGENT++
http://www.agentpp.com
http://www.mibexplorer.com
http://www.mibdesigner.com
More information about the SNMP4J
mailing list