users@shoal.java.net

Re: [Shoal-Users] Multicast channel configuration

From: Shreedhar Ganapathy <Shreedhar.Ganapathy_at_Sun.COM>
Date: Thu, 22 May 2008 11:04:18 -0700

Hi Valentin
Interesting post.

???????? ???????? wrote:
> Hi everyone,
>
> We are building a bridge between two clusters made with Shoal and ran
> into problems with multicast communication.
We have never tried communication between two network separate Shoal
clusters. So this will be somewhat of a new area for us. Are these two
clusters in separate networks?
> From the documentation on Shoal or JXTA I was unable to figure out how
> to set parameters such as packet TTL, outbound network interface and
> source address for the packets.
>
> Can someone tell me if it is possible and how can I change this
> parameters?
Look in ServiceProviderConfigurationKeys.java
<https://shoal.dev.java.net/source/browse/shoal/gms/src/java/com/sun/enterprise/ee/cms/core/ServiceProviderConfigurationKeys.java?rev=1.7&view=markup>.
We don't expose TTL and source network address properties. TTL would
assume that your router would allow multicast traffic through to other
networks which often cannot be assumed.
Shoal provides the abstraction of network address through logical names
of the members so that when you ask for source member token through the
API, you get the logical name of the member. The network address
translation for member name to network address is performed by Jxta for
you.

What you can do is to have one or more members of one cluster be
participants in the other cluster with member type Spectator. i.e Member
X of Cluster A can be CORE member in Cluster A and SPECTATOR member in
Cluster B.
This will allow member of one cluster to be part of another cluster.
Your application on this member can perform functions that are required
to have state transfer between these two clusters.
Now, if these clusters are on different networks, you will also need to
this member as a bootstrapping node so that it can use virtual multicast
through Jxta to route all messages through to the other cluster. This
setting (look in the crosssubnetdemo.sh test located at shoal/gms ) has
to be exposed on all members who want to communicate in that cluster.

Again we have not experimented this so would appreciate it if you can
share results of your experiment on this community alias.
>
> Background: application nodes run on Java 1.5/1.6 most of the time
> deployed inside Solaris 10 Containers on multihomed Fire servers. I
> wrote a Java application that uses multicast sockets that is able to
> talk in such configuration if all the parameters are set up - so the
> network is probably fine.
>
> Regards,
> Valentin.