[jdev] architecture questions

[Peter Saint-Andre]

On Fri, Feb 20, 2004 at 10:30:59AM -0800, Joanne wrote:

Hi Joanne,It's good to see folks from Jambotech on the list -- I recall
some involvement from people there a few years ago. BTW, coding
questions belong on this list, not JADMIN (that's for server
administration), so no need to cross-post.

> (1) message queuing/processing
> It seems that jabber's queuing mechanism is only dependent on a a client's "online" status. If a client is offline, jabber will automatically queue the messages in an offline store. But as soon as the client's online presence is detected, jabber will start "pushing" all queued messages to it automatically. Assuming our jabber client had no queuing mechanism, we would have to block while processing each message. Would this block->process type of method work well within the jabber framework in order to take advantage of its built in queuing mechanism? I wrote a simple client to test this type of processing and on the surface it appears to work, but I was just wondering if anyone might see other factors/issues/caveats I might not be considering before I choose this type of implementation.

First, you may be confusing "Jabber" wiht specific implementations. Most
server implementations will do offline queueing as you describe,
but that's a matter of implementation and configuration. Also, the
message flood that you refer to on login can be addressed with the
protocol defined in JEP-0013.

> (2) scalability & redundancy
> I would like to connect multiple jabber clients to the same jabber server. Also keep in mind that my clients will only be available within the internal network, so I'm exploiting the A2A (application 2 application) capability of jabber. Although each jabber client does the same thing, they would each need to have unique jids. But I also read that I could run multiple clients with the same jid but with different resource identifiers. Jabber would then decide which client to forward the message to based on the client's presence priority. Unfortunately, this doesn't do any load balancing, but it would allow me to take down one client without disrupting any message processing (since jabber would just forward messages to the next priority client). Is my thinking correct on this?

You could write a custom load-balancing module for the jabberd server,
but you're right that such functionality does not exist out of the box
for delivery to the various resources for a client.

> (3) load balancing
> To truly achieve load balancing, it appears to me that I would need to implement a custom jabber component. All messages would be addressed to this component jid (instead of a client jid as described above). The component would then decide which of the available clients it would forward messages to. However, it appears that we would loose the queuing capability of jabber since store/forward is not available to components (according to "Programming Jabber"), so does that mean I would have to implement my own queuing mechanism within the component? I could probably get away with sacrificing the load balancing component and just rely on the presence priority forwarding of jabber to support redundancy in the short run, but eventually, I could build the load balancing component later. 

Your component would have to do its own queueing.

I probably missed your previous messages to the list -- what kind of
application are you trying to write?

Peter

-- 
Peter Saint-Andre
Jabber Software Foundation
http://www.jabber.org/people/stpeter.php