To fix this issue, you need to bind to your cluster domain from the clustering component. see http://jabberd.jabberstudio.org/dev/docs/component.shtml for more info.
On 23/09/05, Gonzalo Barrio <[EMAIL PROTECTED]> wrote: > Well I take off the restriction in jabberd2 and all start working fine. > So I going to make a tar.gz and share my cluster component. (Written the > JCR) > > Thanks Pedro. > > Gonzalo Barrio wrote: > > > Ok, I finished the C component that made the clustering feature. It's > > simple but I can't make it work fine, because of a restriction in > > jabberd2. > > One component can't insert a packet as another. Here is an example > > > > I setup 2 PyMSN components: > > msn-1.hq.novamens.com > > msn-2.hq.novamens.com > > > > And the cluster component as: > > msn.hq.novamens.com > > > > Start up all three components (first the transports) and then I get > > this message from the router component of jabberd2: > > > > sx (io.c:205) decoded read data (574 bytes): <iq > > from='msn.hq.novamens.com' type='result' to='hq.novamens.com'><query > > xmlns='http://jabber. > > org/protocol/disco#info'><identity category='gateway' type='msn' > > name='MSN Transport'/><identity category='conference' type='text' > > name='MS > > N Transport Chatrooms'/><feature > > var='http://jabber.org/protocol/disco'/><feature > > var='jabber:x:conference'/><feature var='jabber:iq:confer > > ence'/><feature var='jabber:iq:register'/><feature > > var='jabber:iq:gateway'/><feature var='jabber:iq:version'/><feature > > var='http://jabber.o > > rg/protocol/commands'/><feature var='vcard-temp'/></query></iq> > > sx (io.c:70) completed nad: <iq xmlns='jabber:component:accept' > > to='hq.novamens.com' type='result' from='msn.hq.novamens.com'><query > > xmlns= > > 'http://jabber.org/protocol/disco#info'><identity name='MSN Transport' > > type='msn' category='gateway'/><identity name='MSN Transport Chatroo > > ms' type='text' category='conference'/><feature > > var='http://jabber.org/protocol/disco'/><feature > > var='jabber:x:conference'/><feature var='j > > abber:iq:conference'/><feature var='jabber:iq:register'/><feature > > var='jabber:iq:gateway'/><feature var='jabber:iq:version'/><feature var=' > > http://jabber.org/protocol/commands'/><feature > > var='vcard-temp'/></query></iq> > > sx (chain.c:119) calling nad read chain > > sx (io.c:124) tag 22 event 6 data 0x80c2608 > > Fri Sep 23 16:06:45 2005 router.c:691 packet from legacy component, > > munging it > > Fri Sep 23 16:06:45 2005 router.c:373 unicast route from > > msn.hq.novamens.com to hq.novamens.com > > Fri Sep 23 16:06:45 2005 [notice] [192.168.1.4, port=27769] tried to > > send a packet from 'msn.hq.novamens.com', but that name is not bound t > > o this component > > Fri Sep 23 16:06:45 2005 router.c:321 packet for legacy component, > > munging > > sx (chain.c:106) calling nad write chain > > sx (io.c:369) queueing for write: <iq xmlns='jabber:client' > > to='hq.novamens.com' type='error' from='msn.hq.novamens.com'><error > > type='cance > > l' code='503'><service-unavailable > > xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/></error><query > > xmlns='http://jabber.org/protocol/disco#info > > '><identity name='MSN Transport' type='msn' > > category='gateway'/><identity name='MSN Transport Chatrooms' > > type='text' category='conference'/ > > ><feature var='http://jabber.org/protocol/disco'/><feature > > var='jabber:x:conference'/><feature > > var='jabber:iq:conference'/><feature var='ja > > bber:iq:register'/><feature var='jabber:iq:gateway'/><feature > > var='jabber:iq:version'/><feature > > var='http://jabber.org/protocol/commands'/> > > <feature var='vcard-temp'/></query></iq> > > > > > > Pedro do you know of some solution, or XCP does not restrict this ? > > > > > > Thanks, > > > > Gonzalo Barrio Linares > > > > PD: If everything works fine I 'm going to publish this. > > > > Pedro Melo wrote: > > > >> Hi, > >> > >> On Sep 15, 2005, at 8:36 PM, Gonzalo Barrio wrote: > >> > >>> Pedro, how many concurrent users have in sapo ? > >> > >> > >> > >> couple of thousands. > >> > >>> Are you using this clustering feature ? > >> > >> > >> > >> I'm moving today to cluster: several instances of pyMSNt > >> load-balanced by JID. > >> > >> The source code will be available (probably GPL) sometime this > >> weekend. It works for me now. It was written in-house, aroun 160 > >> lines of perl code, mostly error recovery and startup. The real > >> loadbalancing is around 3 or 4 lines :) > >> > >>> What hard and soft ? > >>> I mean msn1, msn2, msn3 ...... all reponding msn.im.sapo.com.pt, > >>> because > >>> I think that I can add this feature on jabberd2 modifying some > >>> things on > >>> the router and sm component. In this way, we can clusterize all kind of > >>> components (except mu-conference I think again) > >> > >> > >> > >> Ok. I can identify 3 types of balancing you need to cover all the > >> situations I faced. Those are: > >> - stateless: you don't care where the stanza's go, just round-robin, > >> least load, whatever, distribute them; > >> - statefull based on 'from': my packets must go to the same > >> instance, like MSN/AIM/ICQ, etc. Basically, any situation where the > >> component keeps a session for you. > >> - statefull based on 'to': text conferencing. you can have several > >> rooms, and some rooms go to chat1 and others go to chat2. Pubsub > >> jep60 might also applied, not a problem for us just yet. > >> > >> Also, right now, I don't care if the instances are up or down. Our > >> balancer get's a packet, hashes the jid to a integer, modulus number > >> of instances, and forwards (using <route>) the original stanza to the > >> choosen destination. > >> > >> The only difference between those three types of algorithm above is > >> the field that you use to distribute the stanzas. > >> > >> I don't think you need to modify anything on the server. You only > >> need a component that takes ownership of your main domain name > >> (msn.im.sapo.pt) in our case, and start N instances of your component. > >> > >> One think that is required: each component must respond to the main > >> domain name and a secondary name. In some server (like XCP that we > >> use), you can have a linkname (based on the ID) and a host filter. > >> Our balancer needs that. We send the stanzas to the linkname, and the > >> stanzas include the main domain name. > >> > >> Notice that our code does not do any kind of rewriting. There is no > >> need to do it. Also, it's just a normal component with a single TCP > >> connection to the server. It does not connect directly to the other > >> instances. All the traffic is through the server. > >> > >> Also, notice that only the stanzas to the main domain go through the > >> balancer. The replies flow directly from the component instances to > >> the client. > >> > >> If you server does not trust the components and checks all the > >> stanzas received to see if they match the from with the linkname, for > >> example, you will have trouble. > >> > >> Finally, the only requirements on the component that you wish to > >> balance are: > >> - they need to support linkname and hostname: pyMSNt supports that > >> with the <useXCP> tag, that's your linkname; > >> - they need to support <route> stanzas: simple really, just drop the > >> <route></route> and use the XML inside as if it came from the socket. > >> > >> Regarding jabberd2, my suggestion would be that you don't implement > >> this inside the server, but as a external component. Oh, and if you > >> write something like this in C, I will be extremely interested :)... > >> On our roadmap is moving xbalance.pl to C, but only if we need it. > >> > >> > >>> Then only thing I don't want to do is to reinvent the weel..... :-) > >> > >> > >> > >> Same here. I searched the web for something like this and found > >> nothing, so I just coded it. > >> > >> I think that if we can agree on a spec we can build one of these > >> components in C and use it with all the jabber servers that support > >> JEP-0100. > >> > >> That would be cool. > >> > >> My problem with C, btw, is that I don't know which library to use as > >> a base of this component. If you have some ideas about that, I would > >> love to ear them. > >> > >> Thanks, > >> -- > >> HIId: Pedro Melo > >> SMTP: [EMAIL PROTECTED] > >> XMPP: [EMAIL PROTECTED] > >> > >> _______________________________________________ > >> py-transports mailing list > >> py-transports@blathersource.org > >> http://www.modevia.com/cgi-bin/mailman/listinfo/py-transports > >> > > > > > > _______________________________________________ > > py-transports mailing list > > py-transports@blathersource.org > > http://www.modevia.com/cgi-bin/mailman/listinfo/py-transports > > > > > _______________________________________________ > py-transports mailing list > py-transports@blathersource.org > http://www.modevia.com/cgi-bin/mailman/listinfo/py-transports > -- - Norman Rasmussen - Email: [EMAIL PROTECTED] - Home page: http://norman.rasmussen.co.za/ From [EMAIL PROTECTED] Fri Sep 23 20:59:10 2005 From: [EMAIL PROTECTED] (Gonzalo Barrio) Date: Fri Sep 23 20:59:21 2005 Subject: [py-transports] PyMSNt 0.10-rc3 In-Reply-To: <[EMAIL PROTECTED]> References: <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> Message-ID: <[EMAIL PROTECTED]> This things has to be done on the PyMSN/PyAIM/PyICQ side. I'm gonna do this on PyMSN and send the changes to James, but all the other transports ? Something is done in PyMSN to make it work on XCP, extend this to jabberd2 component is not so dificult. Thanks again. Gonzalo Barrio Linares. Norman Rasmussen wrote: >To fix this issue, you need to bind to your cluster domain from the >clustering component. see >http://jabberd.jabberstudio.org/dev/docs/component.shtml for more >info. > >On 23/09/05, Gonzalo Barrio <[EMAIL PROTECTED]> wrote: > > >>Well I take off the restriction in jabberd2 and all start working fine. >>So I going to make a tar.gz and share my cluster component. (Written the >>JCR) >> >>Thanks Pedro. >> >>Gonzalo Barrio wrote: >> >> >> >>>Ok, I finished the C component that made the clustering feature. It's >>>simple but I can't make it work fine, because of a restriction in >>>jabberd2. >>>One component can't insert a packet as another. Here is an example >>> >>>I setup 2 PyMSN components: >>> msn-1.hq.novamens.com >>> msn-2.hq.novamens.com >>> >>>And the cluster component as: >>> msn.hq.novamens.com >>> >>>Start up all three components (first the transports) and then I get >>>this message from the router component of jabberd2: >>> >>>sx (io.c:205) decoded read data (574 bytes): <iq >>>from='msn.hq.novamens.com' type='result' to='hq.novamens.com'><query >>>xmlns='http://jabber. >>>org/protocol/disco#info'><identity category='gateway' type='msn' >>>name='MSN Transport'/><identity category='conference' type='text' >>>name='MS >>>N Transport Chatrooms'/><feature >>>var='http://jabber.org/protocol/disco'/><feature >>>var='jabber:x:conference'/><feature var='jabber:iq:confer >>>ence'/><feature var='jabber:iq:register'/><feature >>>var='jabber:iq:gateway'/><feature var='jabber:iq:version'/><feature >>>var='http://jabber.o >>>rg/protocol/commands'/><feature var='vcard-temp'/></query></iq> >>>sx (io.c:70) completed nad: <iq xmlns='jabber:component:accept' >>>to='hq.novamens.com' type='result' from='msn.hq.novamens.com'><query >>>xmlns= >>>'http://jabber.org/protocol/disco#info'><identity name='MSN Transport' >>>type='msn' category='gateway'/><identity name='MSN Transport Chatroo >>>ms' type='text' category='conference'/><feature >>>var='http://jabber.org/protocol/disco'/><feature >>>var='jabber:x:conference'/><feature var='j >>>abber:iq:conference'/><feature var='jabber:iq:register'/><feature >>>var='jabber:iq:gateway'/><feature var='jabber:iq:version'/><feature var=' >>>http://jabber.org/protocol/commands'/><feature >>>var='vcard-temp'/></query></iq> >>>sx (chain.c:119) calling nad read chain >>>sx (io.c:124) tag 22 event 6 data 0x80c2608 >>>Fri Sep 23 16:06:45 2005 router.c:691 packet from legacy component, >>>munging it >>>Fri Sep 23 16:06:45 2005 router.c:373 unicast route from >>>msn.hq.novamens.com to hq.novamens.com >>>Fri Sep 23 16:06:45 2005 [notice] [192.168.1.4, port=27769] tried to >>>send a packet from 'msn.hq.novamens.com', but that name is not bound t >>>o this component >>>Fri Sep 23 16:06:45 2005 router.c:321 packet for legacy component, >>>munging >>>sx (chain.c:106) calling nad write chain >>>sx (io.c:369) queueing for write: <iq xmlns='jabber:client' >>>to='hq.novamens.com' type='error' from='msn.hq.novamens.com'><error >>>type='cance >>>l' code='503'><service-unavailable >>>xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/></error><query >>>xmlns='http://jabber.org/protocol/disco#info >>>'><identity name='MSN Transport' type='msn' >>>category='gateway'/><identity name='MSN Transport Chatrooms' >>>type='text' category='conference'/ >>> >>> >>>><feature var='http://jabber.org/protocol/disco'/><feature >>>> >>>> >>>var='jabber:x:conference'/><feature >>>var='jabber:iq:conference'/><feature var='ja >>>bber:iq:register'/><feature var='jabber:iq:gateway'/><feature >>>var='jabber:iq:version'/><feature >>>var='http://jabber.org/protocol/commands'/> >>><feature var='vcard-temp'/></query></iq> >>> >>> >>>Pedro do you know of some solution, or XCP does not restrict this ? >>> >>> >>>Thanks, >>> >>>Gonzalo Barrio Linares >>> >>>PD: If everything works fine I 'm going to publish this. >>> >>>Pedro Melo wrote: >>> >>> >>> >>>>Hi, >>>> >>>>On Sep 15, 2005, at 8:36 PM, Gonzalo Barrio wrote: >>>> >>>> >>>> >>>>>Pedro, how many concurrent users have in sapo ? >>>>> >>>>> >>>> >>>>couple of thousands. >>>> >>>> >>>> >>>>>Are you using this clustering feature ? >>>>> >>>>> >>>> >>>>I'm moving today to cluster: several instances of pyMSNt >>>>load-balanced by JID. >>>> >>>>The source code will be available (probably GPL) sometime this >>>>weekend. It works for me now. It was written in-house, aroun 160 >>>>lines of perl code, mostly error recovery and startup. The real >>>>loadbalancing is around 3 or 4 lines :) >>>> >>>> >>>> >>>>>What hard and soft ? >>>>>I mean msn1, msn2, msn3 ...... all reponding msn.im.sapo.com.pt, >>>>>because >>>>>I think that I can add this feature on jabberd2 modifying some >>>>>things on >>>>>the router and sm component. In this way, we can clusterize all kind of >>>>>components (except mu-conference I think again) >>>>> >>>>> >>>> >>>>Ok. I can identify 3 types of balancing you need to cover all the >>>>situations I faced. Those are: >>>> - stateless: you don't care where the stanza's go, just round-robin, >>>>least load, whatever, distribute them; >>>> - statefull based on 'from': my packets must go to the same >>>>instance, like MSN/AIM/ICQ, etc. Basically, any situation where the >>>>component keeps a session for you. >>>> - statefull based on 'to': text conferencing. you can have several >>>>rooms, and some rooms go to chat1 and others go to chat2. Pubsub >>>>jep60 might also applied, not a problem for us just yet. >>>> >>>>Also, right now, I don't care if the instances are up or down. Our >>>>balancer get's a packet, hashes the jid to a integer, modulus number >>>>of instances, and forwards (using <route>) the original stanza to the >>>>choosen destination. >>>> >>>>The only difference between those three types of algorithm above is >>>>the field that you use to distribute the stanzas. >>>> >>>>I don't think you need to modify anything on the server. You only >>>>need a component that takes ownership of your main domain name >>>>(msn.im.sapo.pt) in our case, and start N instances of your component. >>>> >>>>One think that is required: each component must respond to the main >>>>domain name and a secondary name. In some server (like XCP that we >>>>use), you can have a linkname (based on the ID) and a host filter. >>>>Our balancer needs that. We send the stanzas to the linkname, and the >>>>stanzas include the main domain name. >>>> >>>>Notice that our code does not do any kind of rewriting. There is no >>>>need to do it. Also, it's just a normal component with a single TCP >>>>connection to the server. It does not connect directly to the other >>>>instances. All the traffic is through the server. >>>> >>>>Also, notice that only the stanzas to the main domain go through the >>>>balancer. The replies flow directly from the component instances to >>>>the client. >>>> >>>>If you server does not trust the components and checks all the >>>>stanzas received to see if they match the from with the linkname, for >>>>example, you will have trouble. >>>> >>>>Finally, the only requirements on the component that you wish to >>>>balance are: >>>> - they need to support linkname and hostname: pyMSNt supports that >>>>with the <useXCP> tag, that's your linkname; >>>> - they need to support <route> stanzas: simple really, just drop the >>>><route></route> and use the XML inside as if it came from the socket. >>>> >>>>Regarding jabberd2, my suggestion would be that you don't implement >>>>this inside the server, but as a external component. Oh, and if you >>>>write something like this in C, I will be extremely interested :)... >>>>On our roadmap is moving xbalance.pl to C, but only if we need it. >>>> >>>> >>>> >>>> >>>>>Then only thing I don't want to do is to reinvent the weel..... :-) >>>>> >>>>> >>>> >>>>Same here. I searched the web for something like this and found >>>>nothing, so I just coded it. >>>> >>>>I think that if we can agree on a spec we can build one of these >>>>components in C and use it with all the jabber servers that support >>>>JEP-0100. >>>> >>>>That would be cool. >>>> >>>>My problem with C, btw, is that I don't know which library to use as >>>>a base of this component. If you have some ideas about that, I would >>>>love to ear them. >>>> >>>>Thanks, >>>>-- >>>>HIId: Pedro Melo >>>>SMTP: [EMAIL PROTECTED] >>>>XMPP: [EMAIL PROTECTED] >>>> >>>>_______________________________________________ >>>>py-transports mailing list >>>>py-transports@blathersource.org >>>>http://www.modevia.com/cgi-bin/mailman/listinfo/py-transports >>>> >>>> >>>> >>>_______________________________________________ >>>py-transports mailing list >>>py-transports@blathersource.org >>>http://www.modevia.com/cgi-bin/mailman/listinfo/py-transports >>> >>> >>> >>_______________________________________________ >>py-transports mailing list >>py-transports@blathersource.org >>http://www.modevia.com/cgi-bin/mailman/listinfo/py-transports >> >> >> > > >-- >- Norman Rasmussen > - Email: [EMAIL PROTECTED] > - Home page: http://norman.rasmussen.co.za/ >_______________________________________________ >py-transports mailing list >py-transports@blathersource.org >http://www.modevia.com/cgi-bin/mailman/listinfo/py-transports > > >