Jack Moffitt
11-04-2008, 04:57 PM
> i cannot use pubsub or chat rooms since we use <iq/> for request-response
> mechanisms [pubsub and chat rooms only spreads out <message/> stanzas afaik,
> unless i'm missing something here].
You're not missing anything. muc and pubsub are both implemented as
<message/>. You could probably extend
a MUC fairly easily to allow <iq/>, but I'm not sure such a thing
makes sense for pubsub.
An alternative is to switch from IQ to a request/response over
<message/> which is also possible, but not as native.
I'll note also that if the pubsub queueing spec were implemented, it
does have such a request response system built in using messages and
iqs. Perhaps you'd like to implement that? :)
> the option i am currently thinking is to use a custom server module [we use
> ejabberd] that creates a route, and load balances incoming stanzas by
> re-addresses them to different jids, each one of those being handled by a
> different client [and hardware]. i.e., some kind of load balancer built in
> ejabberd.
ejabberd already contains a load balancer, although perhaps it is too
simple for your current use case. You can connect the a component to
ejabberd many times, and it will deliver stanzas to it in round robin
fashion. The best solution if you need more sophisticated load
balancing would be to extend the component plugin for ejabberd and add
in some options which control the load balancing behavior.
Another solution might be to make a single component that implements
an <iq/> accessible queue. Ie, it takes requests for jobs, and pops
them of the queue. Someone else adds jobs to the queue. Your worker
clients can just pop off jobs, do the work, and respond. The
advantage here is that you don't have to muck about changing anything
in ejabberd.
That said, your proposed solution certainly sounds like it will work.
Let us know how it goes!
jack.
> mechanisms [pubsub and chat rooms only spreads out <message/> stanzas afaik,
> unless i'm missing something here].
You're not missing anything. muc and pubsub are both implemented as
<message/>. You could probably extend
a MUC fairly easily to allow <iq/>, but I'm not sure such a thing
makes sense for pubsub.
An alternative is to switch from IQ to a request/response over
<message/> which is also possible, but not as native.
I'll note also that if the pubsub queueing spec were implemented, it
does have such a request response system built in using messages and
iqs. Perhaps you'd like to implement that? :)
> the option i am currently thinking is to use a custom server module [we use
> ejabberd] that creates a route, and load balances incoming stanzas by
> re-addresses them to different jids, each one of those being handled by a
> different client [and hardware]. i.e., some kind of load balancer built in
> ejabberd.
ejabberd already contains a load balancer, although perhaps it is too
simple for your current use case. You can connect the a component to
ejabberd many times, and it will deliver stanzas to it in round robin
fashion. The best solution if you need more sophisticated load
balancing would be to extend the component plugin for ejabberd and add
in some options which control the load balancing behavior.
Another solution might be to make a single component that implements
an <iq/> accessible queue. Ie, it takes requests for jobs, and pops
them of the queue. Someone else adds jobs to the queue. Your worker
clients can just pop off jobs, do the work, and respond. The
advantage here is that you don't have to muck about changing anything
in ejabberd.
That said, your proposed solution certainly sounds like it will work.
Let us know how it goes!
jack.