I don't know what your line 700 looks like, unfortunately. But the segfault we resolved locally by a simple null pointer check.
Carsten -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Petros Kataras Sent: Freitag, 21. November 2014 17:13 To: Equalizer Developer List Subject: Re: [eq-dev] RSP / mutlicast details 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.ht >> ml 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 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
