Ok, looking again at the logs on the slaves side I realized that they were trying to resolve the hostname of the master so I added it to the known hosts and RSP seems to work now..
I m having other issues though that do not manifest when running the app normally without RSP. I have a shared object that actually seems to map and work fine but I get an LBUNREACHABLE from objectStore.cpp line 700 . Reading through the source I can't figure exactly where the issue might lie and as I mentioned the object seems to register and map properly on the master and client side respectively.. Besides that I am also getting a segfault when exiting the app inside EventConnection::getNotifier() when running the RSP config. This segfault happens also with eqPly / seqPly and so on but I don't really have time to debug it right now... Anyways I think for now I am gonna stick with unicast and maybe later on I ll give it a try again.. Thanks for the help anyways.. Cheers, Petros On Nov 21, 2014, at 10:11 AM, Petros Kataras <[email protected]> wrote: > Hi Rohn, > > thanks for your reply! > > I am pretty sure that multicast works properly on the network setup since I > tested with a simple node.js client/server script and I am able to receive > multicast in this case.. > > The only problem that I faced in that case was that I had to listen to > 0.0.0.0 in order to actually receive the multicast. i.e If I would try to > listen for multicast explicitly on the 172 interface then I was not > receiving anything.. > > I am not sure though if this is expected behavior with node.js or not.. > > Also something that I didn't mention on my previous post is that the appNode > has two network interfaces; one to communicate with the external world and > one for the local subnet ( of course with the multicast route configured for > the appropriate interface ). As I said though this seems to work in general > from the small test that I did with node.js. > > I will try with coNetPerf today also and I will come back to you with more > details also on where exactly the appNode hangs. > > Thanks again, > Petros > > On Nov 21, 2014, at 8:25 AM, ROHN Carsten <[email protected]> wrote: > >> Hey Petros, >> >> The config you posted will not send any RSP packets. Clients listen to RSP, >> but the appNode doesn't send anything. If you uncomment the commented stuff >> on the appNode, RSP starts working, and that's probably why it hangs ;) >> >> There could be a lot of reasons for hanging. I recommend to experiment with >> coNetPerf first, if multicast really works in your network with your setup. >> >> Server1: coNetPerf -s RSP#102400#239.172.18.57#172.18.57.12#12333## >> Server2: coNetPerf -s RSP#102400#239.172.18.57#172.18.57.13#12333## >> Serverx: ... >> Client: coNetPerf -c RSP#102400#239.172.18.57#172.18.57.11#12333## >> >> Does this test show packets being sent to the servers as you expect it? If >> yes, your problem is not multicast, but how Collage handles multicast. And >> that's where the debugging starts, I'm afraid. Where exactly does it hang? >> >> Cheers, >> Carsten >> >> PS: A general note: We found multicast to be working pretty poorly for >> mapping, so we had to use the *CM::push() functions to distribute data and >> mapped the created objects to VERSION_NONE afterwards. This scales pretty >> well. >> >> -----Original Message----- >> From: [email protected] >> [mailto:[email protected]] On Behalf Of Petros.Kataras >> Sent: Donnerstag, 20. November 2014 18:40 >> To: [email protected] >> Subject: [eq-dev] RSP / mutlicast details >> >> Hello, >> >> I am trying to setup a cluster with 1 master and 9 slaves that will use RSP >> for mapping and delta distribution but I am not sure how the config file >> should look exactly on the master side aka appNode.. >> >> Here is the config file that I have created so far: >> >> #Equalizer 1.2 ascii >> >> global >> { >> EQ_WINDOW_IATTR_HINT_FULLSCREEN ON >> EQ_WINDOW_IATTR_HINT_SWAPSYNC OFF >> } >> >> server >> { >> connection { hostname "172.18.57.11" } >> config >> { >> appNode >> { >> name "appNode" >> host "sw-master" >> connection{ type TCPIP } >> connection >> { >> #type RSP >> #port 12333 >> #interface "172.18.57.11" >> #hostname "239.172.18.57" >> hostname "172.18.57.11" >> } >> pipe >> { >> device 0 >> window >> { >> name "master" >> attributes { hint_fullscreen OFF } >> viewport [ .0 .0 1920 1080 ] >> channel { name "master-channel" } >> } >> } >> } >> node >> { >> name "node1" >> host "sw-renderer01" >> connection{ type TCPIP } >> connection >> { >> type RSP >> port 12333 >> interface "172.18.57.12" >> hostname "239.172.18.57" >> } >> pipe >> { >> device 0 >> window >> { >> name "node1" >> viewport [ 0 0 1 1 ] >> channel { name "node1-channel" } >> } >> } >> } >> node >> { >> name "node2" >> host "sw-renderer02" >> connection{ type TCPIP } >> connection >> { >> hostname "239.172.18.57" >> interface "172.18.57.13" >> type RSP >> port 12333 >> } >> pipe >> { >> device 0 >> window >> { >> name "node2" >> viewport [ 0 0 1 1 ] >> channel { name "node2-channel" } >> } >> } >> } >> node >> { >> name "node3" >> host "sw-renderer03" >> connection{ type TCPIP } >> connection >> { >> hostname "239.172.18.57" >> interface "172.18.57.14" >> type RSP >> port 12333 >> } >> pipe >> { >> device 0 >> window >> { >> name "node3" >> viewport [ 0 0 1 1 ] >> channel { name "node3-channel" } >> } >> } >> } >> node >> { >> name "node4" >> host "sw-renderer04" >> connection{ type TCPIP } >> connection >> { >> hostname "239.172.18.57" >> interface "172.18.57.15" >> type RSP >> port 12333 >> } >> pipe >> { >> device 0 >> window >> { >> name "node4" >> viewport [ 0 0 1 1 ] >> channel { name "node4-channel" } >> } >> } >> } >> node >> { >> name "node5" >> host "sw-renderer05" >> connection{ type TCPIP } >> connection >> { >> hostname "239.172.18.57" >> interface "172.18.57.16" >> type RSP >> port 12333 >> } >> pipe >> { >> device 0 >> window >> { >> name "node5" >> viewport [ 0 0 1 1 ] >> channel { name "node5-channel" } >> } >> } >> } >> node >> { >> name "node6" >> host "sw-renderer06" >> connection{ type TCPIP } >> connection >> { >> hostname "239.172.18.57" >> interface "172.18.57.17" >> type RSP >> port 12333 >> } >> pipe >> { >> device 0 >> window >> { >> name "node6" >> viewport [ 0 0 1 1 ] >> channel { name "node6-channel" } >> } >> } >> } >> node >> { >> name "node7" >> host "sw-renderer07" >> connection{ type TCPIP } >> connection >> { >> hostname "239.172.18.57" >> interface "172.18.57.18" >> type RSP >> port 12333 >> } >> pipe >> { >> device 0 >> window >> { >> name "node7" >> viewport [ 0 0 1 1 ] >> channel { name "node7-channel" } >> } >> } >> } >> node >> { >> name "node8" >> host "sw-renderer08" >> connection{ type TCPIP } >> connection >> { >> hostname "239.172.18.57" >> interface "172.18.57.19" >> type RSP >> port 12333 >> } >> pipe >> { >> device 0 >> window >> { >> name "node8" >> viewport [ 0 0 1 1 ] >> channel { name "node8-channel" } >> } >> } >> } >> node >> { >> name "node9" >> host "sw-renderer09" >> connection{ type TCPIP } >> connection >> { >> hostname "239.172.18.57" >> interface "172.18.57.20" >> type RSP >> port 12333 >> } >> pipe >> { >> device 0 >> window >> { >> name "node9" >> viewport [ 0 0 1 1 ] >> channel { name "node9-channel" } >> } >> } >> } >> >> layout { view { }} >> canvas >> { >> layout 0 >> wall >> { >> bottom_left [ -1.6 -.5 -1 ] >> bottom_right [ 1.6 -.5 -1 ] >> top_left [ -1.6 .5 -1 ] >> } >> swapbarrier {} >> >> segment { viewport [ 0 0 1 1 ] channel "master-channel" } >> segment { viewport [ 0.00000000000000000000 0 >> 0.11111111111111111111 1 ] channel "node1-channel" } >> segment { viewport [ 0.11111111111111111111 0 >> 0.11111111111111111111 1 ] channel "node2-channel" } >> segment { viewport [ 0.22222222222222222222 0 >> 0.11111111111111111111 1 ] channel "node3-channel" } >> segment { viewport [ 0.33333333333333333333 0 >> 0.11111111111111111111 1 ] channel "node4-channel" } >> segment { viewport [ 0.44444444444444444444 0 >> 0.11111111111111111111 1 ] channel "node5-channel" } >> segment { viewport [ 0.55555555555555555555 0 >> 0.11111111111111111111 1 ] channel "node6-channel" } >> segment { viewport [ 0.66666666666666666666 0 >> 0.11111111111111111111 1 ] channel "node7-channel" } >> segment { viewport [ 0.77777777777777777777 0 >> 0.11111111111111111111 1 ] channel "node8-channel" } >> segment { viewport [ 0.88888888888888888888 0 >> 0.11111111111111111111 1 ] channel "node9-channel" } >> } >> } >> } >> >> Now the appNode section is the one that I am not sure about ... Going >> through older posts I see that people were subscribing also the appNode on >> the multicast group but if I try to do that by uncommenting the relevant >> lines in the config file then everything hangs. >> >> On the other hand if I just run the config file as it is, then I can see >> that the slaves properly subscribe on the appropriate multicast group and >> the sample app runs properly but I am not sure if then the traffic is routed >> through the multicast address or not.. >> >> The clients are auto-launched by the server btw and I haven't tried manually >> pre-starting everything. >> >> So, does the appNode need to subscribe to the multicast group or is it >> sufficient to leave it like this ? >> >> In case that the appNode actually has to subscribe to the multicast group do >> you see something wrong with the above config file that it would cause it to >> hang?? >> >> Thanks for any insights, >> Petros >> >> >> >> -- >> View this message in context: >> http://software.1713.n2.nabble.com/RSP-mutlicast-details-tp7586748.html >> Sent from the Equalizer - Parallel Rendering mailing list archive at >> Nabble.com. >> >> _______________________________________________ >> eq-dev mailing list >> [email protected] >> http://www.equalizergraphics.com/cgi-bin/mailman/listinfo/eq-dev >> http://www.equalizergraphics.com >> This email and any attachments are intended solely for the use of the >> individual or entity to whom it is addressed and may be confidential and/or >> privileged. >> >> If you are not one of the named recipients or have received this email in >> error, >> >> (i) you should not read, disclose, or copy it, >> >> (ii) please notify sender of your receipt by reply email and delete this >> email and all attachments, >> >> (iii) Realtime Technology does not accept or assume any liability or >> responsibility for any use of or reliance on this email. >> >> For other languages, go to http://www.3ds.com/terms/email-disclaimer >> >> _______________________________________________ >> eq-dev mailing list >> [email protected] >> http://www.equalizergraphics.com/cgi-bin/mailman/listinfo/eq-dev >> http://www.equalizergraphics.com > > > _______________________________________________ > eq-dev mailing list > [email protected] > http://www.equalizergraphics.com/cgi-bin/mailman/listinfo/eq-dev > http://www.equalizergraphics.com _______________________________________________ eq-dev mailing list [email protected] http://www.equalizergraphics.com/cgi-bin/mailman/listinfo/eq-dev http://www.equalizergraphics.com
