This may have been covered many times before, but just in case it helps someone, here is a summary of my experience with using net-snmp in a large network. Specifically, I use it to talk to thousands of SNMPv2 and SNMPv3 agents using just one UDP socket in a process that runs continuously.
The net-snmp library uses linear linked lists for sessions, requests and usmuser data. That would normally be OK, but does not scale so well for this use-case. So I had to make a few small changes: (1) I still create a separate netsnmp-session for each remote agent IP, but force them all to use the same UDP socket. (2) I turn off the v3 engine-id probe hooks so I can send and process those requests manually. (3) I do my own select() using hash tables keyed by reqid and msgid to map back to the right netsnmp-session. There is no blocking. (4) I do my own timeout check using a time-sorted tree. (5) I changed the library to expose this function so I can feed response PDUs back to the library directly: extern void snmp_sess_receive_packet(void *sessp, u_char *packet, int length, struct sockaddr *from, int from_len); (6) I exposed this function to help construct engine-id probes: extern int usm_build_probe_pdu(netsnmp_pdu **pdu); (6) I changed the userList in snmplib/snmpusm.c to be a hash-table of userLists keyed by engine-id (but the logic within each list is otherwise unchanged). These were the smallest changes I could make. There don't seem to be any significant bottlenecks now. Neil P.S. I was also tempted to set SNMPV3_IGNORE_UNAUTH_REPORTS=1 because otherwise the library delivers an unexpected extra callback after a failed engine-id probe, but it seemed better to harden the logic to handle unexpected callbacks gracefully. _______________________________________________ Net-snmp-coders mailing list Net-snmp-coders@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
