I wanted to ask whether there are any current or future plans to support using java.nio (e.g., DatagramChannel / NIO-based channels) for creating UDP data sockets in SNMP4J, instead of the current java.net.Socket–based approach.
In our use case, we have some requirements that would be much easier to address with NIO (non-blocking I/O, custom channel configuration, integration with selectors, etc.). This would likely require changes or an extension around DefaultUdpTransportMapping.
Hi Nihal, there are currently no plans to (directly) use java.nio for UDP TransportMappings. What are the “requirements” that you have that cannot be realised with the current implementation?
snmp4j using java.nio / DatagramChannel isn’t likely happening in core. it’s not a drop-in swap — once you move away from the current DefaultUdpTransportMapping, you’re changing threading, timing, and error semantics that SNMP4J relies on.
for most cases people cite (scale, tuning, throughput), the existing blocking UDP model already works if you handle concurrency and backpressure above the socket layer.
if you truly need selector integration or shared event loops, the only realistic path is a custom transport mapping built around DatagramChannel. core snmp4j is optimized for deterministic behavior, not NIO flexibility.