HI, First, there really needs to be a session per SNMP agent to support future development. And secondly, it does seem like the code needs to "share" sockets to keep from depleting them. My 2 cents.
Regards, /david t. perkins At 10:45 AM 8/3/2004 -0400, Glenn MacGregor wrote: >Sorry, to clarify a bit. My project is not multi-threaded yet, it is going to be, but >we are not there yet. > >My requirement for only one session is because I am polling thousands of different >devices. I don't want the number of device I can poll limited by the FD_SET_SIZE in >the Net-SNMP library's select call. Also It seems like a waste of resources to open a >session for every device if I am using UDP as the transport. There is not need to >waste the file descriptors or the time it takes to find the active fd after select >returns. I do realize that it is necessary to create a session for each device if you >are using TCP as the transport, I am not. > >[EMAIL PROTECTED] wrote: > >>Several open-source projects use Net-SNMP in multi-threaded applications. >>Cacti is successfully using snmp_sess_open (with mutex locks) in its >>"C" based tool "cactid". >>Please explain the requirement "only one snmp_session". >> >> >>>From: Glenn MacGregor <[EMAIL PROTECTED]> >>>Date: 2004/08/03 Tue AM 09:58:47 EDT >>>To: [EMAIL PROTECTED] >>>Subject: Retry and timeout proposed change >>> >>>Hi All, >>> >>>I am writing an application which requires me to open one snmp_session and poll >>>many devices. I do this by changing the transport_data of the pdu to contain the >>>correct address (I only use UDP so I can do this??). Another requirement is that >>>every different device needs to have it's own timeout and retries. So I looked into >>>changing the timeout and retires in the session before I send to each device. >>> >>>Testing and looking through the net-snmp-5.1.1 code I found that changing the >>>timeout works, but changing the retries doesn't. This seems to be due to the >>>implementation of the retries in the snmp_request_list structure. The timeout is >>>stored from the session when the original is created and we cacl the expire time >>>from that. The retries is incremented upon each retry and tested against what is in >>>the session at the time of the retry. >>> >>>I am looking to change that to copy the retry value from the session at the time of >>>the original send (as with timeout) and decrement it in the request_list until it >>>is 0 at which time we have failed. What do you think of this? Is there a reason >>>that timeout and retries work differently? I would be glad to post a patch if this >>>is an excepted solution. Please let me know. >>> >>>Thanks >>> >>> Glenn >>> >>> >>>------------------------------------------------------- >>>This SF.Net email is sponsored by OSTG. Have you noticed the changes on >>>Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now, >>>one more big change to announce. We are now OSTG- Open Source Technology >>>Group. Come see the changes on the new OSTG site. www.ostg.com >>>_______________________________________________ >>>Net-snmp-coders mailing list >>>[EMAIL PROTECTED] >>>https://lists.sourceforge.net/lists/listinfo/net-snmp-coders > > > >------------------------------------------------------- >This SF.Net email is sponsored by OSTG. Have you noticed the changes on >Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now, >one more big change to announce. We are now OSTG- Open Source Technology >Group. Come see the changes on the new OSTG site. www.ostg.com >_______________________________________________ >Net-snmp-coders mailing list >[EMAIL PROTECTED] >https://lists.sourceforge.net/lists/listinfo/net-snmp-coders ------------------------------------------------------- This SF.Net email is sponsored by OSTG. Have you noticed the changes on Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now, one more big change to announce. We are now OSTG- Open Source Technology Group. Come see the changes on the new OSTG site. www.ostg.com _______________________________________________ Net-snmp-coders mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
