That will inevitably fail. While on command sender side, you will be able to use DirectUserTarget to workaround the duplicate engine IDs issue, the command responder side would fail to accept at least one of the command sender.
Using the sender IP address to distinguish engine ID is not applicable because sender IPs can change any time.
You need to do it manually/programatically. There is no automation/timeout as this is operation security relevant. After the removal, the engine ID time has to be resynched with the “valid” owner of the engine ID.
You can use USM.removeEngineTime to remove an engine ID from the USM engine time store.
Any successful communication does not matter, the second engine ID time can break the trust at any time. If the second engine is removed from the subnet and the command sender has currently the time of the other instance, then that communication can continue.
I see, that “done()” do all needed things about USM and EngineId processing,
but looks like inside “done()” method “discoverAuthoritativeEngineID()” also removes and recreates EngineId stuff.
Does it mean, that both EngineId duplication situation in subnet and EngineId update (or device removing from subnet) are processed correct from the box in my implementation)?
Yes, that fluent code will reset the engine time each time to make sure that the embedded USM user of the direct target works.
Although this has many advantages regarding reliability, there are a few drawbacks:
Additional network overhead traffic needed
Engine ID discovery must be allowed and theoretically lowers security regarding man-in-the-middle attacks, but I think the latter does not really matter because alternatives are more complicated and therefore do not improve security in fact.
If you allow, what do you think about such approach of mine to recreate target every time?
Or if I know that I will work with the target in some minutes again better (for some reasons) to collect/store targets created once?
In my understanding “recreate” gives more benefits in general reliability of communication (using “fluent” of cause).