fredo writes:
fredo> my first look into gsnmp:
fredo> i saw a couple of 'not thread safe' comments, why so ? because fredo> glib-2.0/2.2 is thread-safe.
Not sure yet. Much of the code is just a hacked version of the code using in gxsnmp which is again rooted to some extend in the BNTG sources. Lots of this code needs to be cleaned up.
fredo> if its for the socket methods, why not port to gnet, paired fredo> with the glib thread-queues makes a really powerful dispatcher fredo> mechanism, instead of the slist ;)~ (but has no ipv6 support fredo> yet).
I am looking into gnet at the moment but it is not yet clear whether gnet has all the things I need (service name lookups come to mind). I also would like to actually integrate things piecewise into gnet (e.g. the ASN/BER module first) so that things can be reused for other protocols (LDAP, Kerberos, COPS-PR, ...).
fredo> one particular problem may arise if you have several different fredo> snmp-tools running on one machine, where each of those believes fredo> in its exlusive right to bind to port 161/udp (one wins the fredo> others loose), so do you really need to make a request from fredo> that specific port ?
I use gsnmp currently only for manager side implementations and in this case it does not bind to 161 so I do not see the problem.
fredo> you could modify the GSnmpTransport struct to include a socket fredo> (gnet or otherwise) and the function-map is already there to fredo> send/recv the pdus.
Yes, as I said, all this needs to be cleaned up quite a bit. The GSnmpTransport really just has to provide framing capabilities for stream based transports. And even this code is missing right now.
/js