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
>
