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
