Need a design suggestion.

[Billy Davis]

All,
 
    I am having an interested problem trying to develop an snmp gui. This
application does SNMP sets, gets, getbulk, getnext, receives trap, and
sends traps. Basically I am developing it for the academic purpose of
leaning the snmp++ library.  I am sorry that this email may become a bit
lengthy, but I assume people will need some background to be able to answer
my question.
 
    In my application ( BTW, it is an MFC Windows application ), I have one
view displaying all the pdu's I receive. I have created a global SNMP
session which is use for the get, getbulk, and getnext command. I have a
modal dialog for doing SNMP sets that manages it's own snmp session. And if
the user starts the notification service to receive traps a seperate thread
is created but it still uses the global SNMP session. For doing sets I have
a modal dialog box that manages it's own session. For sending traps I have a
modless dialog box that also manages it's own session. 
 
    My problem arouse when I added the Send trap Dialog box. In one
scenario, I have one instance of my application listening for traps and I
send a trap from another instance of my application,  the target is
localhost. And everything works beautifully. In another scenario, I listen
for traps and send from the same instance of the application, and again the
target is the localhost.  Under this scenario the application freezes. Now,
I know this problem is probably a windows message queue problem! But, has
anyone had a similar experience? and if so, how would I go about solving it?
 
    Also, once I started trouble-shooting this problem I really started to
noticed how messy my snmp session handling had gotten. From looking at the
old HP SNMP++ Browser application (from an different distribution of the
library I have), I noticed that they used seperate modless dialogs that
manage individual session. Is it better to create a session for every snmp
command you execute? or, is it o.k. to reuse a global session for all
commands?
 
Thanks,
Billy Davis
 
    
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.agentpp.org/pipermail/agentpp/attachments/20011212/d0b0bf90/attachment.htm