Quoting [EMAIL PROTECTED]: > 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.
Can you elaborate on the multi-threading techniques? I am very interested in doing this sooner rather than later, but I haven't had the time to dig in and see what problems might exist. > > 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 ? That is an option, but I really can't afford to use a socket for each device I am polling because it will cut the number of device I can poll from one location in half. That is not an option. If you have any ideas on a solution to "share" a socket between multiple snmp_session structures I would be glad to work on it. It seems to me that forcing a client to use a socket for each device polled is not a scalable solution. > > > > > 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. I flag it as a failed poll. > > Note that you can change where FD_SET_SIZE is used > if your operating system allows > increasing the per-process limit for file descriptors. Once you get near 1500 or so the time it takes to scan the fd_set begins to degrade the performance of the application. > > Also, memory is cheaper these days than developer time. That would > help with thousands of snmp_session structures to manage! Just seems like a waste to me, I don't mind creating an snmp_session for every device, but opening a new socket for each device will not work. > > 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 > > >> > > > > > > > > > > > > Glenn MacGregor HighStreet Networks ------------------------------------------------- This mail sent through IMP: http://horde.org/imp/ ------------------------------------------------------- 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
