If you are seriously considering multi-threading, it may be easier in the long run to build using multi-threading techniques earlier in your development. Incorrect assumptions will be uncovered sooner, and you will be able to scale to larger number of devices easier, when you take the multi-thread hit earlier.
On the other hand, if you have to meet a milestone on a pilot project Real Soon Now, keeping the deliverable simple and small may have more concrete benefits! If you are communicating with thousands of devices, at some point you may find issues with the bandwidth when communicating with them from a single location. Can you run your application with smaller lists of target devices from several servers ? You already mentioned an issue you've discovered with your approach with timeouts. Using UDP as you know increases the work factor that either you let Net-SNMP do (it does a fairly good job), or your application will need to mimic the buffering afforded by the socket mechanism. What will your application do if a read() does not return all of the data that was sent from a device ? That may be specious, I'm sorry to increase the FUD factor here. Note that you can change where FD_SET_SIZE is used if your operating system allows increasing the per-process limit for file descriptors. Also, memory is cheaper these days than developer time. That would help with thousands of snmp_session structures to manage! Regards, -Mike Slifcak > > From: Glenn MacGregor <[EMAIL PROTECTED]> > Date: 2004/08/03 Tue AM 10:45:31 EDT > To: [EMAIL PROTECTED] > CC: [EMAIL PROTECTED] > Subject: Re: Retry and timeout proposed change > > 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
