Sounds like to me that the jabberd2 component spec needs to be updated so that you can have multiple components allowed to send for a domain, and one of them receives for that domain.
Sort of like a half-bind, perhaps bind-mode="both" or bind-mode="send", if you know what I mean. When that spec was last considered within my earshot, it sounded like that the jabbed2 team would be very happy to clean it up, and release it as an official spec. It sounds like we need to prod them to do this, because more component services are being written where a plain single hostname legacy connection won't do. I'm thinking about your component, as well as the component that use a seperate domain for groupchats (like yahoo-transport does, and msn-c used to). Also I think wild-card binding would be useful (i.e. *.component.server), so that you can set up wild-card dns entries, etc... On 24/09/05, Gonzalo Barrio <[EMAIL PROTECTED]> wrote: > Well, the only modification that I did to jabberd2 is disabled the check > that does not permit the send :-P Bad thing. > I don't have XCP but I think that if you have it you will not require > more changes, because Pedro Melo has a cluster module written in perl > that works with that. I make the same component but in C, just for > performance. > Actually it works in jabberd2 with some lines of router.c commented out, > but if James does not make the jabberd2 component changes I will. > > On monday I send the component, if anyone need it early, I send a copy, > but I like to test it a little more. > > It support the three kinds of cluster said by Pedro: > - Sateful by the "from" part (For any kind of transport) > - Sateful by the "to" part (For muc) > - Sateless (for juds or other components that not require an interaction > between both parts, client and component) > > Saludos, > > Gonzalo Barrio Linares. > > Norman Rasmussen wrote: > > >I have alpha patches for jabberd2's component protocol for xmpp.py. > > > >Is http://jabberd.jabberstudio.org/dev/docs/component.shtml the same as XCP? > > > >also, when you did the jabberd2 mods, are you talking about anything > >on http://j2.openaether.org/mediawiki/index.php/Clustering or have you > >written your own mods? (if so you should probably put a note up on > >the wiki talk page about it) > > > >I noticed that the avatar branch of PyMSNt has a XCP option, would > >this mean that it requires no furthur changes, or does it still need > >more tweaking? > > > >On 23/09/05, Gonzalo Barrio <[EMAIL PROTECTED]> wrote: > > > > > >>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 > >>> > >>> > >>> > >>> > >>> > >> > >> > >> > > > > > >-- > >- 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 > > > > > > > > -- - Norman Rasmussen - Email: [EMAIL PROTECTED] - Home page: http://norman.rasmussen.co.za/ From [EMAIL PROTECTED] Sat Sep 24 02:14:01 2005 From: [EMAIL PROTECTED] (Trejkaz) Date: Sat Sep 24 02:14:20 2005 Subject: [py-transports] Changing nick on MSN Message-ID: <[EMAIL PROTECTED]> Where did the ability go to change my nickname on MSN? That was useful... can I turn it back on somehow? TX -- Email: Trejkaz Xaoza <[EMAIL PROTECTED]> Web site: http://trypticon.org/ Jabber ID: [EMAIL PROTECTED] GPG Fingerprint: 9EEB 97D7 8F7B 7977 F39F A62C B8C7 BC8B 037E EA73 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://modevia.com/pipermail/py-transports/attachments/20050924/e2b2cd49/attachment.pgp From [EMAIL PROTECTED] Sat Sep 24 02:47:18 2005 From: [EMAIL PROTECTED] (Andreas van Cranenburgh) Date: Sat Sep 24 02:47:21 2005 Subject: [py-transports] Changing nick on MSN In-Reply-To: <[EMAIL PROTECTED]> References: <[EMAIL PROTECTED]> Message-ID: <[EMAIL PROTECTED]> On Sat, Sep 24, 2005 at 12:14:01PM +1000, Trejkaz wrote: > Where did the ability go to change my nickname on MSN? > > That was useful... can I turn it back on somehow? the transport uses the nickname from your vCard, now that msn also supports status messages (they call it "personal message"). or where you already looking there? -- Andreas [ http://unstable.nl | xmpp:[EMAIL PROTECTED] ] [ callto:ils.seconix.com/[EMAIL PROTECTED] ] -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://modevia.com/pipermail/py-transports/attachments/20050924/7fbaeec4/attachment.pgp From [EMAIL PROTECTED] Sat Sep 24 12:35:50 2005 From: [EMAIL PROTECTED] (James Bunton) Date: Sat Sep 24 12:36:22 2005 Subject: [py-transports] [patch] JEP-0085 support for PyMSNt In-Reply-To: <[EMAIL PROTECTED]> References: <[EMAIL PROTECTED]> Message-ID: <[EMAIL PROTECTED]> Looks good, but you do still need to send the message events notification. I'd say that <x xmlns="jabber:x:event"/> always needs to be sent unless we have detected support for chatstates. Also yeah, the chatstates support notification should only be sent once. If you can fix those two things then I'll commit it for the release after 0.10. --- James On 15/09/2005, at 12:07 AM, Andreas van Cranenburgh wrote: > Here's my first attempt at supporting JEP-0085 a.k.a. "chatstates". > Only > typing notifications for now, not yet the "contact closed conversation" > messages. > > I think there's a slight problem caused by PyMSNt repeating composing > or > not-composing events, this is against the JEP [1] > > I've tried to support both JEP-0022 and JEP-0085 at the same time, but > haven't come up with how this will go for the initial message, so now > it > only advertises chatstates if the MSN contact talks first. > > This patch has been tested and known to interoperate with Gajim [2] > > [1] http://www.jabber.org/jeps/jep-0085.html#bizrules-rep > [2] http://www.gajim.org > > -- > Andreas [ http://unstable.nl | xmpp:[EMAIL PROTECTED] ] > [ callto:ils.seconix.com/[EMAIL PROTECTED] ] > <pymsn-jep0085.patch>_______________________________________________ > py-transports mailing list > py-transports@blathersource.org > http://www.modevia.com/cgi-bin/mailman/listinfo/py-transports
