users@shoal.java.net

Non-multicast Rendezvous peers

From: Jim Marino <jim.marino_at_gmail.com>
Date: Sun, 1 Mar 2009 21:58:52 -0800

Hi,

I've been looking at enabling non-multicast discovery using rendezvous
peers and a few questions have come up. First, I'm unclear on how a
rendezvous peer should be configured. Specifically, how to specify the
tcp port a rendezvous peer should listen on. I came across the
following parameters:

JxtaConfigConstants.IS_BOOTSTRAPPING_NODE

I assume if set to true, this will enable the node as a rendezvous and
relay node. And, the second parameter:

JxtaConfigConstants .VIRTUAL_MULTICAST_URI_LIST

This collection appears to be used to specify the URIs of rendezvous
nodes. But I also noticed the following in NetworkManager.startDomain():

         if (isRendezvousSeed && rendezvousSeedURIs.size() > 0) {
             config = new
NetworkConfigurator(NetworkConfigurator.RDV_NODE +
NetworkConfigurator.RELAY_NODE, storeHome.toURI());
             //TODO: Need to figure out this process's seed addr from
the list so that the right port can be bound to
             //For now, we only pick the first seed URI's port and let
the other members be non-seeds even if defined in the list.
             String myPort = rendezvousSeedURIs.get(0);
         .....

My impression is this will be problematic when configuring multiple
rendezvous peers. Shouldn't there be an explicit configuration for the
TCP port to use? Related to this, I also noticed the
NetworkConfigurator in NetworkManager.startDomain() is always enabled
with multicast. Should this be optional? If there was a way to
configure the TCP port and to specify whether multicast should be
used, would that enable the use of a single rendezvous instance? Or,
am I missing something that is a deeper problem?

Also, Shreedhar mentioned there is an issue with setting up multiple
rendezvous peers. I'm not familiar with the codebase so if someone
could briefly describe what the issue is, it would help point me in
the right direction.

Thanks,
Jim