users@shoal.java.net

Questions regarding ServiceProviderConfigurationKeys...

From: Olaf Krische <java_at_ecopatz.de>
Date: Tue, 28 Oct 2008 21:50:19 +0100

Hello again,

ok, this is what i have in the moment:

- a bunch of hosts connected to a hub. the hub propagates
incoming messages to the other hostss except to the originating host.

I wanna replace the hub by adding at least two rendezvous peers, which
will inherit the task of propagating the messages to all other peers.

What i want to avoid is that each host maintains connections to all
other hosts on the net. They always should use the rendezvous peers
to find hosts and to send messages to them. As well i can not use
multicast.

Now the questions:

- IS_BOOTSTRAPPING_NODE

> Represents a key whose value is set to true if this node will be a
> bootstrapping host for other members to use for discovery purposes.
> This is particularly useful when multicast traffic is not supported in the
> network or cluster members are located outside a multicast supported
> network area. Setting the value of this to true requires specifying a
> URI corresponding to this member process's IP address and port with tcp
> protocol, as a value in the VIRTUAL_MULTICAST_URI_LIST property. See
> below for the VIRTUAL_MULTICAST_URI_LIST property

This tells me, when i setup a bootstrapping node, this node must also
be given in the VIRTUAL_MULTICAST_URI_LIST ? Why?

- VIRTUAL_MULTICAST_URI_LIST

> This enum represents a key the value of which is a comma separated list
> of initial bootstrapping tcp addresses. This address list must be
> specified on all members of the cluster through this property.

> Typically an address uri would be specified as tcp://ipaddress:port
> The port here could be any available unoccupied port.

No, it must be the ipaddress:port of the bootstrapping node, right?

> Specifying this list is helpful particularly when cluster members are
> located beyond one subnet or multicast traffic is disabled. Note: The
> implementation in Shoal at the moment only uses the first address in
> this list and ignores the rest. This is an enhancement that is not yet
> completed.

Hrm. So this means, i would be stuck to one Hub again? What if this node
gets lost?

Maybe i just do not understand it right, is a rendezvous node really
only necessary to find hosts? Once a host/peers has discovered its
peers, it will send messages directly? Mh, no. This i do not want.

Well, iam frustrated anyways. The more i dive into jxta, the more i get
lost. Sometimes the dudes talk about RDV, and then they say Rendezvous
again, then there is seed uri or seeds uri, and then i cant even
simulate many hosts on one host withine a junit test.

Sigh :)