The notification originator sends the notifications using the protocols and addresses configured in the Notification MIB. That MIB can be remotely administered. Unless special code is written, this lets the user freedom to choose between UDP or TCP. The notification originator assumes the required transport mappings have been added.
Unfortunately, adding a protocol mapping has the other side-effect of adding a listener for that protocol. The TCP transport mapping has a provision for this. If the transport is created without an address, then the TCP transport is send-only and the listener thread is not started. The UDP transport is missing that feature. If you add a transport mapping, it always creates a listener thread. If the UDP transport could be created in send-only mode, then we could modify the best-practice to always add both UDP and TCP transports with or without an address. This would satisfy the notification originator requirement that a transport mapping is available. I realize that this scenario only comes into play when the agent is listening only on TCP and a notification target has a UDP destination. I am not sure how likely this is. On the other hand, it seems an unnecessary limitation that SNMP4J-Agent requires a UDP listener to be able to send notifications over UDP. _______________________________________________ SNMP4J mailing list [email protected] http://lists.agentpp.org/mailman/listinfo/snmp4j
