OS> This function previously existed for snmpd, but was OS> coded right in snmpd.c and agent_registry.c. This OS> change, moves these changes to a new unit called OS> fd_event_manager.c which can then be used in other OS> places (snmptrapd).
RS> Good idea. I only see a few minor changes, but I don't see why this RS> couldn't make it into 5.3. Cool. If you let me know I can make the changes and resubmit the patch. OS> This patch is setup for a second patch which allows OS> SNMP traps to be published to an arbitrary application OS> over TCP/IP. RS> Another good idea. My only question is, how is it published? As a PDU? RS> the formatted text string? Basically snmptrapd listens on a well-known port (configurable) for subscribers. It usually would use the loopback, but I guess it is possible to use any network interface on the local machine (again configurable). It publishes a PDU (netsnmp_pdu) that has been packed into a byte stream and then can be unpacked on the other end. I suspect there will be some comments here since I wasn't exactly sure what should be packed and what should be left alone. I mostly packed and unpacked everything in the netsnmp_pdu struct. Through trial and error (and memory leaks) I found that some data was not really owned by the pdu, and didn't need to be packed/unpacked. I separated the PDU code into its own unit called snmp_pdu.c, but when I asked about this to the coders list some time back they said it should just be left in the snmp_api.c file for now awaiting major restructuring of the file in the future. This would be a code change for my patch so if you have suggestions where I should put this code, left me know since I'll probably need to make changes regardless. I suspect some more work could be done to automate the reception and call a callback on the subscriber side. This would make it trivial and transparent to receive the traps and call a user supplied callback in any net-snmp bound management application. I never made this addition since the management application I was working with had its own middleware and it wouldn't have worked to have the net-snmp API actually make the connection to the trap publisher under the covers. Well actually it would have worked, I just didn't have time to make it work then:) Instead I just used my middleware to make the connection and when data came in over the connection, I just unpacked it with netsnmp_unpack_snmp_pdu() and called my callback. That said, I do think the automation of this subscriber would be valuable for people building management applications from scratch. I envision that they could just make a couple of calls once this is implemented and they'll be in business. netsnmp_init_snmp_trap_subscriber(); netsnmp_add_snmp_trap_subscription_handler(callback); Where callback is a C function to be called when a trap is received from the publisher. Right now, the they would need to do the select() and read() and netsnmp_unpack_snmp_pdu() which really isn't that much harder, but is not as cool. -Sten ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ Net-snmp-coders mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
