Hi,
to be sure to connect over the right interface, you can use IP-adresses
./12ClusterServer.exe -w 123.222.111.1:1234
./13ClusterClient.exe -fData/tie.wrl 123.222.111.1:1234
for a direct connect you have to specify the protocol on client and
server side.
nothing Stream socket
-m Multicast
-p Socket pipeline
additionally you can specify an interface for the connection
./13ClusterClient.exe -fData/tie.wrl 123.222.111.1:1234 -i 123.222.111.2
where 123.222.111.2 is the ip of the client interface.
unfortunately the options -p and -i are only available in the
testClusterClient
and testClusterServer. I added them to the tutorials in the current CVS.
Marcus
Andreas Zieringer wrote:
Hi,
can you try to connect directly with the ip addresses, this feature
was added after the 1.4.0 release so you have to use a current cvs
version.
./12ClusterServer.exe -w machine:1234
./13ClusterClient.exe -fData/tie.wrl machine:1234
where "machine" is the hostname of the computer or a ip address, and
"1234" a port number.
Andreas
Hi Akos,
Hi Khai,
On Fri, 10 Jun 2005, Khai Binh Duong wrote:
I have the problem, that one of my server in a Windows PC
Cluster does
not find the client. The server runs on the frontend of the
Cluster,
which has two networkadapter.
If I deactivate the other network, everything works fine. I
think the
server search in the wrong network for the client. I try to
set explicit
the IP-address of the client in the server, but it doesn't work.
As Gerrit has already suggested, this is most probably due to
a routing
bug. I'd go even further and say that this is very probably due to
incorrectly routing the multicast packets that OpenSG uses to
discover the
rendering servers (even when setting the IP adresses
explicitly). On Linux
you usually issue a command like:
/sbin/route add -net 224.0.0.0 netmask 240.0.0.0 dev eth1
I imagine on Windows it's very similar but I'll leave that up to the
reader as an exercise (or maybe someone on the list with Windows
networking knowledge can step in) as I don't know too much
about Windows
networking internals. :)
Yours,
Akos
I also believe that is a routing bug with the multicast packets.
The routing you mention exist for both adapters:
Destination Mask Gateway Interface
224.0.0.0 240.0.0.0 10.0.254.34 10.0.254.34
224.0.0.0 240.0.0.0 192.168.0.34 192.168.0.34
It makes no different if I delete one of these routing entry.
It works only if I deactivate one of the network.
I'm at a loss with this strange problem.
Khai Binh Duong
-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games. How far can you
shotput
a projector? How fast can you ride your desk chair down the office
luge track?
If you want to score the big prize, get to know the little guy. Play
to win an NEC 61" plasma display: http://www.necitguy.com/?r=20
_______________________________________________
Opensg-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/opensg-users
-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games. How far can you shotput
a projector? How fast can you ride your desk chair down the office luge track?
If you want to score the big prize, get to know the little guy.
Play to win an NEC 61" plasma display: http://www.necitguy.com/?r=20
_______________________________________________
Opensg-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/opensg-users
