[Standards] XEP-0225: Multiple Connections Per JID?

Peter Saint-Andre stpeter at stpeter.im
Fri Feb 8 21:15:44 UTC 2008

Daniel Henninger wrote:
> I guess this would end up being up to the server implementation, 

You betcha.

> but
> right now resource -> priority handling could cause some problems
> here if you treated it just like a client.  

Who said anything about priorities? That's a presence concept, not a
resource binding concept.

> The idea here is to
> distribute the load amongst multiple instances of the external
> component.  With clients, the higher priority would be getting all of
> the pubsub.example.org packets, and seeing as we don't have
> priorities here, would end up falling into the semi-confusion of
> "what to do with the same priority".  So what do you go with, last
> one that connected?  First one that connected?  Last one that was
> active?  In this case that's a little useless ... effectively we'd
> need round robin or something along those lines.  But ... I suppose
> that boils down to "up to the server to decide on that".  


> Are there
> any guidelines anywhere that even help decide what one should do if
> implementing this for clients or is it completely up to the server to
> decide how this works?  

Completely up to the server implementation (and perhaps also the
deployment policy).

> It might be nice, at least here, to have some
> strict rules.  "Bare JID references will be round robin" or something
> like that.  I suppose the setup could be part of the local security
> policy as well --- let the server admin decide.  Of course that
> doesn't help if one external component expects the server to work one
> way, and one expects it to work a different way.  Hell, it may even
> be something that needs to be configured server side to work,
> "period".  Of course, that's more confusion on the part of the server
> administrator -- more steps to have to run through.  

Life is hard. If you want to run a highly-scalable service with
clustering and round-robin components and all that, you have to expect
the effort to involve some brain-damage. And if you don't want the
brain-damage, don't get into the business of hosting highly-scalable
XMPP services.

> Anyway, am I reading this right as resources seem to be the way to
> go, even if it might require some folk to rethink how they're
> using/referencing components?

Yes, I think XEP-0225 will require a significant rethink of component
handling in certain implementations. But the idea is that the rethink
will be worth the effort since the new approach will be more flexible
etc. So so we hope. :)


Peter Saint-Andre

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 7338 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20080208/8e346e81/attachment.bin>

More information about the Standards mailing list