RE: [dsdp-tm-dev] RSEDefaultNewConnectionWizard and Protocol.getPeers()

["Stieber, Uwe" <Uwe.Stieber@xxxxxxxxxxxxx>]

Hi Jacques,

> Not sure if you have a chance to verify the attached 
> patch. I've guarded the SystemConnectionForm.verify
> call in getNextPage, but I don't have a quick chance
> to verify it.
> 
> This patch works just fine, as expected. Until an update I'm 
> keeping a home-backed patched  RSEDefaultNewConnectionWizard 
> in my package and can extend RSEAbstractNewConnectionWizard.

Committed the patch. You should get it with the next update if building
from sources or with the next regular build.
 
> I have another problem though: when I call
Protocol.getLocator().getPeers()
> at the very beginning of my performFinish(), Protocol.getLocator()
returns
> "null" until a couple of seconds and when I finally have a locator,
locator.getPeers() 
> returns an incomplete HashMap (containing only TCPLocal) 
> until a dozen of seconds.
> Interestingly, if I wait before pressing the finish button, 
> it is useless and I have to press the button to trigger what 
> seems a network discovery initialization period.
> What about it?
> How can I know when Protocol and ILocator are ready to be 
> used for my purpose?

Well, if the TCF plugins are not started yet, first access to the
plugins will fire them up. Protocol can be always used, there is no
initialization to this one. The discovery model is a broadcast model.
Means, getLocator().getPeers() does not query the peers, it listens to
UDP packages to gain knowlegde about peers (in the same subnet). If you
access the peers at a point of time, the local locator service hasn't
received any UDP package yet, it will provide you only with the TCPLocal
peer.

Eugene, am I right?

Thanks, Best regards, Uwe :)