Is mutiple sessions for SNMP over TLS with same address possible?

[anjali.k_m]

Hi
We created multi threaded dispatcher for SNMP instance with 3 threads

During SNMP transactions, I noticed 3 sessions actually getting established.

And while closing connection as below,

I noticed only one session getting closed!

After checking snmp4j code for debugging, noticed that
TLSTM.sockets is single socketEntry per address.
private Map<Address, SocketEntry> sockets = new Hashtable<Address, SocketEntry>();

If so, can’t we have multiple session per targetAddress?

[AGENTPP]

@anjali.k_m

During SNMP transactions, I noticed 3 sessions actually getting established.

I do not think the above is true. Could you please share debug logging that shows it?

The multi-threaded dispatcher is dispatching with multiple threads nothing else.

[anjali.k_m]

Observations are as below

netstat shows 3 connections established

We dispatched 3 transactions almost same time, snmp4j logs showing looking up for connection but returned null (I think as socket entry is missing and checked at almost same time)

Running delegate tasks showing 3 different local ports for same target

I couldn’t attach log file.
In case any further logs snapshots necessary, I would share.

Thanks,
Anjali

[AGENTPP]

What SNMP4J version are you using?

[anjali.k_m]

We are using latest 2.8.9 SNAPSHOT jar as received for fix from another thread with latest jdk 1.8 available: jdk1.8.0_321
https://snmp.app/dist/snapshot/org/snmp4j/snmp4j/2.8.9-SNAPSHOT/snmp4j-2.8.9-20220215.112730-2.jar

SNMP4j over TLS stuck at "Key is writable"

OK, thanks for confirming that the issue is still present with the latest jdk1.8.0_321 build. The source of the issue seems to be some weird state of the SSLEngine (status CLOSED but handshake status NEED_WRAP). I have im proved the SNMP4J 2.8.x code to cover this case too in TLSTM.ServerThread.runDelegatedTasks. The following new if-statement ensures that the socket is registered with the outQueue to write out-data: case CLOSED: if (status == SSLEngineResult.HandshakeStatus.NOT_HAND…

[AGENTPP]

This issue has been fixed in SNMP4J 3.4.4 and later. It is not related to the usage of the MultiThreadedMessageDispatcher.

[AGENTPP]

The latest SNMP4J 2.8.9 SNAPSHOT now contains the SJF-235 fix for socket leakage on concurrent TLS connection opening too.

[anjali.k_m]

Thanks @AGENTPP
One query on threads in multithreaded dispatcher for TLS. Might be basic but getting the clarification
Are the threads asynchronous in nature that would be able to cater to multiple requests at the same time instead of waiting/blocked on the SNMP response to be received from SNMP client to which request is sent?
i.e., is there a blocking call (like socket read/write) involved?

[AGENTPP]

Already the regular dispatcher is non-blocking. The only drawback of the regular dispatcher compared to the multi-threaded dispatcher is the following:

Regular dispatcher will wait to deliver/call the response listener for the next response after the current response listener returns.
The multi-threaded dispatcher will call response listeners concurrently (limited to the thread pool size).

That’s all.