hi!
my first look into gsnmp:
i saw a couple of 'not thread safe' comments, why so ? because glib-2.0/2.2 is thread-safe.
if its for the socket methods, why not port to gnet, paired with the glib thread-queues makes a really powerful dispatcher mechanism, instead of the slist ;)~ (but has no ipv6 support yet).
one particular problem may arise if you have several different snmp-tools running on one machine, where each of those believes in its exlusive right to bind to port 161/udp (one wins the others loose), so do you really need to make a request from that specific port ?
you could modify the GSnmpTransport struct to include a socket (gnet or otherwise) and the function-map is already there to send/recv the pdus.
much like (with gnet):
typedef struct _GSnmpUdpTransport { GSnmpTDomain tdomain; /* transport domain */ gchar *name; /* name of the transport domain */ GUdpSocket *socket; gboolean (*sendMessage) ( GUdpSocket *socket, GInetAddr *targetHost, guchar *outgoingMessage, guint outgoingMessageLength ); gboolean (*receiveMessage) ( GUdpSocket *socket, GInetAddr **sourceHost, guchar **incomingMessage, guint *incomingMessageLength ); gboolean (*resolveAddress) ( gchar *targetHost, guint16 port, GInetAddr **address ); gboolean (*initSocket) ( GUdpSocket **socket ); gboolean (*closeSocket) ( GUdpSocket *socket ); } GSnmpUdpTransport;
typedef struct _GSnmpTcpTransport { GSnmpTDomain tdomain; /* transport domain */ gchar *name; /* name of the transport domain */ GTcpSocket *socket; gboolean (*sendMessage) ( GTcpSocket *socket, guchar *outgoingMessage, guint outgoingMessageLength ); gboolean (*receiveMessage) ( GTcpSocket *socket, guchar **incomingMessage, guint *incomingMessageLength ); gboolean (*resolveAddress) ( gchar *targetHost, guint16 port, GInetAddr **address ); gboolean (*initSocket) ( GInetAddr *targetHost, GTcpSocket **socket ); gboolean (*closeSocket) ( GTcpSocket *socket ); } GSnmpTcpTransport;
do you see the light ?
-- fredo
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
participants (2)
-
fredo
-
Juergen Schoenwaelder