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 >> [email protected] >> http://www.modevia.com/cgi-bin/mailman/listinfo/py-transports >> > > > _______________________________________________ > py-transports mailing list > [email protected] > http://www.modevia.com/cgi-bin/mailman/listinfo/py-transports >
