Hi Shreedhar,
Thanks for reply.
Looks like my explanation on configuration was a bit vague. What we are
trying to do is the following: we setup a cluster in network segment A and
have one detached node which can possibly run in a network segment B. Our
intention is to fully employ cluster capability in segment A and to be able
to send messages to nodes in this segment from segment B. The goal is to
hide possible node failures in A from detached node. For messaging we
currently use sendMessage(String, byte[]) on group handle.
A bit different problem may occur on multihomed systems. See
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4701650 on details.
To conclude: there are two separate problems.
First one: if Shoal runs separated by network segments a TTL needs to be
set.
Second: on multihomed systems due to Java's implementation of
MulticastSocket selection of outgoing network interface and address for
packet is unspecified by default and may lead to situation where data is
sent to wrong interface with wrong address.
To fix first I should use ServiceProviderConfigurationKeys to update TTL to
correct value. I see no solution now to address second one.
2008/5/22 Shreedhar Ganapathy <Shreedhar.Ganapathy_at_sun.com>:
> 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.
>
>