No subject

the
second socket where NO Session has been established. Therefore the
MasterAgent only responds with 257 (no session open).

So we have several problems here:
 - A response PDU for a "broken session" opens a new socket, that will
"overwrite" the socket of a newly created session.
 - A session does not have an associated socket but only an associated
address.
 - The TransportMapping does not know anything about the session to =
which a
packet belongs and therefore should NOT be allowed to choose the socket =
on
which to send.

I clearly see, that it will definitely not be a minor patch to fix these
problems resulting in the race condition described above. However I am =
now
trying to defer the reconnection process by 5 seconds. This is however =
only a
workaround. This will allow any pending outgoing messages to be sent
(possibly opening a new socket). After 5 seconds all pending tasks =
should be
finished and a new socket connection may already be established which =
will
then in turn be used to open the new session.

Regarding the loss of the connection: EACH connection loss follows the =
same
pattern. The "request1 =3D> response1, request2 =3D> response2" pattern =
gets out
of sync ("request1, request2 =3D> response1, response2") and then =
obviously the
MasterAgent closes the connection. This however (without having read the
AgentX RFC) appears to me as a valid scenario that is not correctly =
handled
by the MasterAgent. Does anybody of you happen to know if such a =
sequence of
requests and responses is permissible in the AgentX Protocol?=20
 - If yes, then the connection loss is obviously triggered by a bug in
NET-SNMP.=20
 - If not, then snmp4j MUST not read a message from the socket before =
the
response for the last read message is still pending.

Best regards
Stephan