[prev in list] [next in list] [prev in thread] [next in thread]
List: spread-users
Subject: [Spread-users] Fwd: about spread multicast the message
From: John Schultz <jschultz () spreadconcepts ! com>
Date: 2012-03-14 17:41:09
Message-ID: 505060BB-F9FC-4EA5-95D7-C169000CBFC3 () spreadconcepts ! com
[Download RAW message or body]
[Attachment #2 (multipart/signed)]
[Attachment #4 (multipart/alternative)]
From: xuansheng mo <moxuansheng@gmail.com>
Date: March 14, 2012 11:35:05 AM EDT
To: John Schultz <jschultz@spreadconcepts.com>
Subject: Re: [Spread-users] about spread multicast the message
hello:
The reason is firewall configuration between m1 and m2. The security policy in m2 \
and it doesn't receive the mulicast message. Now all works well, enjoying.
Thanks!
2012/3/12 John Schultz <jschultz@spreadconcepts.com>
The daemons are not forming a membership together for some reason.
It could be that you have asymmetric communication in your network where m2's traffic \
can get to m1 but not m1's traffic doesn't get to m2. That could be caused by \
firewalls or misconfiguration of multicast in your network.
Alternatively, their configuration files may be different, although it is not \
apparent from your email's text, such that they compute different configuration \
hashes and, therefore, refuse to acknowledge each other's existence. Try using the \
exact same configuration file (i.e. - copy it from one host to the other) for both \
daemons.
When you start the two daemons, if things are working properly, then after a short \
while they should print out that they've formed a membership with one another. If \
they don't and instead print out singleton memberships, then the likely culprit is \
one of the above issues.
Cheers!
-----
John Lane Schultz
Spread Concepts LLC
Phn: 301 830 8100
Cell: 443 838 2200
On Mar 11, 2012, at 8:34 AM, xuansheng mo wrote:
BTW:
I use the tcpdump in m1: tcpdump -i en1 -n 'dst 225.0.1.1', when spuser in m2 \
join/leave or send message, the m1 can receive the package: 10.0.0.5.33401 > \
225.0.1.1.3333: UDP, length 133 But spuser in m1 could not receive the msg from same \
group in m2.
2012/3/11 xuansheng mo <moxuansheng@gmail.com>
hello all:
I installed the spread toolkit in my OS, and config the spread.conf to run under \
multicast type.
The segment is below(m1 is my localhost)
Spread_Segment 225.0.1.1:3333 {
m1 10.0.0.4
m2 10.0.0.5
}
when the daemon run, I use the supser to test it.
spuser -s 3333 -u user1 | j spread1 | j spread2
spuser -s 3333 -u user2 | j spread | j spread1
spuser -s 3333 -u user3 | j spread1 | j spread
and user1 send the message to group 'spread1', the user3 can receive the message.
All it works well in localhost.
But I start spread daemon on host m2.
The segment is below(m2 is my localhost)
Spread_Segment 225.0.1.1:3333 {
m1 10.0.0.4
m2 10.0.0.5
}
First I connect the m1 to test.
spuser -s 3333@10.0.0.4 -u user4 | j spread1 | j spread2
and the user4 can receive the message from user1.
but , the spuser -s 3333 -u user4 | j spread1 | j spread2 just connect the m2 \
locally.
And user4 could not receive the message from m1 with same group.
(It seems the two daemon couldn't exchange message each other, From the architecture \
about spread,
it show in http://www.cnds.jhu.edu/pub/papers/cnds-2004-1.pdf, Each daemon keeps \
track of processes residing on its machine and participating in group communication).
So, Does my config file is right ? Or something wrong with it?
Thanks in advance.
Mo xuansheng
_______________________________________________
Spread-users mailing list
Spread-users@lists.spread.org
http://lists.spread.org/mailman/listinfo/spread-users
[Attachment #7 (unknown)]
<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; \
-webkit-line-break: after-white-space; "><div><div><span \
style="font-family:'Helvetica'; font-size:medium; color:rgba(0, 0, 0, 1);"><b>From: \
</b></span><span style="font-family:'Helvetica'; font-size:medium;">xuansheng mo \
<<a href="mailto:moxuansheng@gmail.com">moxuansheng@gmail.com</a>></span></div><div \
style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: \
0px;"><span style="font-family:'Helvetica'; font-size:medium; color:rgba(0, 0, 0, \
1);"><b>Date: </b></span><span style="font-family:'Helvetica'; \
font-size:medium;">March 14, 2012 11:35:05 AM EDT<br></span></div><div \
style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: \
0px;"><span style="font-family:'Helvetica'; font-size:medium; color:rgba(0, 0, 0, \
1);"><b>To: </b></span><span style="font-family:'Helvetica'; font-size:medium;">John \
Schultz <<a href="mailto:jschultz@spreadconcepts.com">jschultz@spreadconcepts.com</a>><br></span></div><div \
style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: \
0px;"><span style="font-family:'Helvetica'; font-size:medium; color:rgba(0, 0, 0, \
1);"><b>Subject: </b></span><span style="font-family:'Helvetica'; \
font-size:medium;"><b>Re: [Spread-users] about spread multicast the \
message</b><br></span></div><br>hello:<div> The reason is firewall \
configuration between m1 and m2. The security policy in m2 and it doesn't receive the \
mulicast message.</div><div> Now all works well, \
enjoying.</div><div> </div><div> Thanks!<br> <br><div \
class="gmail_quote">2012/3/12 John Schultz <span dir="ltr"><<a \
href="mailto:jschultz@spreadconcepts.com">jschultz@spreadconcepts.com</a>></span><br><blockquote \
class="gmail_quote" style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; \
margin-left: 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); \
border-left-style: solid; padding-left: 1ex; position: static; z-index: auto; "> The \
daemons are not forming a membership together for some reason.<br> <br>
It could be that you have asymmetric communication in your network where m2's traffic \
can get to m1 but not m1's traffic doesn't get to m2. That could be caused by \
firewalls or misconfiguration of multicast in your network.<br>
<br>
Alternatively, their configuration files may be different, although it is not \
apparent from your email's text, such that they compute different configuration \
hashes and, therefore, refuse to acknowledge each other's existence. Try using \
the exact same configuration file (i.e. - copy it from one host to the other) for \
both daemons.<br>
<br>
When you start the two daemons, if things are working properly, then after a short \
while they should print out that they've formed a membership with one another. \
If they don't and instead print out singleton memberships, then the likely \
culprit is one of the above issues.<br>
<br>
Cheers!<br>
<br>
-----<br>
John Lane Schultz<br>
Spread Concepts LLC<br>
Phn: 301 830 8100<br>
Cell: 443 838 2200<br>
<div><div class="h5"><br>
On Mar 11, 2012, at 8:34 AM, xuansheng mo wrote:<br>
<br>
BTW:<br>
I use the tcpdump in m1: tcpdump -i en1 -n 'dst 225.0.1.1', when spuser in m2 \
join/leave or send message, the m1 can receive the package:<br> 10.0.0.5.33401 > \
225.0.1.1.3333: UDP, length 133<br> But spuser in m1 could not receive the msg from \
same group in m2.<br> <br>
<br>
<br>
2012/3/11 xuansheng mo <<a \
href="mailto:moxuansheng@gmail.com">moxuansheng@gmail.com</a>><br> hello all:<br>
I installed the spread toolkit in my OS, and config the spread.conf to run under \
multicast type.<br> <br>
The segment is below(m1 is my localhost)<br>
<br>
Spread_Segment <a href="http://225.0.1.1:3333/" target="_blank">225.0.1.1:3333</a> \
{<br> m1 10.0.0.4<br>
m2 10.0.0.5<br>
}<br>
<br>
when the daemon run, I use the supser to test it.<br>
<br>
spuser -s 3333 -u user1 | j spread1 | j spread2<br>
<br>
spuser -s 3333 -u user2 | j spread | j spread1<br>
<br>
spuser -s 3333 -u user3 | j spread1 | j spread<br>
<br>
and user1 send the message to group 'spread1', the user3 can receive the message.<br>
<br>
All it works well in localhost.<br>
<br>
But I start spread daemon on host m2.<br>
<br>
The segment is below(m2 is my localhost)<br>
<br>
Spread_Segment <a href="http://225.0.1.1:3333/" target="_blank">225.0.1.1:3333</a> \
{<br> m1 10.0.0.4<br>
m2 10.0.0.5<br>
}<br>
<br>
First I connect the m1 to test.<br>
<br>
spuser -s <a href="mailto:3333@10.0.0.4">3333@10.0.0.4</a> -u user4 | j spread1 | j \
spread2<br> <br>
and the user4 can receive the message from user1.<br>
<br>
but , the spuser -s 3333 -u user4 | j spread1 | j spread2 just connect the m2 \
locally.<br> <br>
And user4 could not receive the message from m1 with same group.<br>
<br>
(It seems the two daemon couldn't exchange message each other, From the architecture \
about spread,<br> <br>
it show in <a href="http://www.cnds.jhu.edu/pub/papers/cnds-2004-1.pdf" \
target="_blank">http://www.cnds.jhu.edu/pub/papers/cnds-2004-1.pdf</a>, Each daemon \
keeps track of processes residing on its machine and participating in group \
communication).<br>
<br>
So, Does my config file is right ? Or something wrong with it?<br>
<br>
Thanks in advance.<br>
<br>
<br>
<br>
Mo xuansheng<br>
<br>
<br>
<br>
<br>
<br>
</div></div>_______________________________________________<br>
Spread-users mailing list<br>
<a href="mailto:Spread-users@lists.spread.org">Spread-users@lists.spread.org</a><br>
<a href="http://lists.spread.org/mailman/listinfo/spread-users" \
target="_blank">http://lists.spread.org/mailman/listinfo/spread-users</a><br> <br>
</blockquote></div><br></div>
</div><br></body></html>
["smime.p7s" (smime.p7s)]
0 *H
01 0 + 0 *H
0m0U Fuc. 76>A0
*H
01 0 UUS10U
U.S. Government1 0
U ECA1"0 U Certification Authorities1>0<U5VeriSign Client External \
Certification Authority - G20 100323000000Z
130322235959Z01 0 UUS10U
U.S. Government1 0
U ECA10U VeriSign, Inc.1 0U Spread Concepts LLC10U John \
Schultz0"0 *H
0
yEx9`
wQ\ F]nټ6?,5!]-AȣYM7%z$ ~.,T JSK F xL(
6 Vw
h.?#ud?IP\fAmߞMi +Z4W
80sDKi?e͝)-12PRiqb-]*25i9rWX"gz0c?o/pT'"9u9ϻ_)@e eEp yAƿ 00QU J0H0F \
D B@http://eca-client-crl.verisign.com/VeriSignECA2048/LatestCRL.crl0U 0 U :)qG 0 U #0
O "P\
!Kr(0&U 0 jschultz@spreadconcepts.com0+t0r0?+03https:// \
eca2048.verisign.com/CA/VeriSignECA2048.cer0/+0#http://eca-client-ocsp.verisign.com0RU \
K0I0G `He 0907++https://www.verisign.com/repository/eca/cps0U 00+ 1US0
*H
;u*)}L-' xoR=vcxVhM`$ 4 C$ .#lg- j1:] 13|)8+@2a GlVTD@ \
xVAt9o@>HhxpQ3Rjh|F!'vOV?Iפ2;yBe=ZNQOH3u \
3Oz5)S,UQd P0m0U i<T: #yh00 *H
01 0 UUS10U
U.S. Government1 0
U ECA1"0 U Certification Authorities1>0<U5VeriSign Client External \
Certification Authority - G20 100323000000Z
130322235959Z01 0 UUS10U
U.S. Government1 0
U ECA10U VeriSign, Inc.1 0U Spread Concepts LLC10U John \
Schultz0"0 *H
0
ڞ(6*m\yw칊S0P mybB;9HQw~zRaC_m<
m`RƬ Dm {`egcSZv
;Ljcc* ~cUGp'}0 QuPEZKƼ*Ptg=U=oBD[|j{f% RjLExn?1c # ^xyDT> \
0 P.re.b_a 00QU J0H0F D \
B@http://eca-client-crl.verisign.com/VeriSignECA2048/LatestCRL.crl0U \
0 U cO'2k?0 U #0 O "P\
!Kr(0&U 0 jschultz@spreadconcepts.com0+t0r0?+03https:// \
eca2048.verisign.com/CA/VeriSignECA2048.cer0/+0#http://eca-client-ocsp.verisign.com0RU \
K0I0G `He 0907++https://www.verisign.com/repository/eca/cps0U 00+ 1US0
*H
h:fq4ϓȲ \
v%Q f}@ D|èAr ?INJEuz UiF;|:7 LX
^}+H[s;M
X6
/㶪;n+j.W !0*>e|1 ]Q㿬; ]i
2ێv]#X#EqE'zl 3ͦLv
\M5qqbrxaQl10001 0 UUS10U
U.S. Government1 0
U ECA1"0 U Certification Authorities1>0<U5VeriSign Client External \
Certification Authority - G2Fuc. 76>A0 + 0 *H 1 *H
0 *H
1
120314174110Z0# *H
1m5>RA0 +71001 0 UUS10U
U.S. Government1 0
U ECA1"0 U Certification Authorities1>0<U5VeriSign Client External \
Certification Authority - G2i<T: #yh00 *H 1 \
01 0 UUS10U U.S. Government1 0
U ECA1"0 U Certification Authorities1>0<U5VeriSign Client External \
Certification Authority - G2i<T: #yh00 *H
2HѪ^oJت27Rkw`X~\N!^},- ߀H?#\FM \
pGb2#57PwOaiD>++},%ʇ 01_>aNfvmz2JvsC()/={ C L7F2nWH
F{@!as@90, JO Ƒh '_
_______________________________________________
Spread-users mailing list
Spread-users@lists.spread.org
http://lists.spread.org/mailman/listinfo/spread-users
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic