[jdev] Re: architecture questions
jlc020404jabber at jambotech.com
Fri Feb 20 13:55:49 CST 2004
"Peter Saint-Andre" <stpeter at jabber.org> wrote in message news:20040220184924.GA23167 at jabber.org...
> 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.
We're specifically using jabberd 1.4.3 as provided from the jabber.org site with no modifications. Based on this implementation, it appears the offline queueing is active by default. I also took a look at JEP-0013 yesterday, but is that something that is supported out of the box? I guess I'm a little confused about what JEPs actually represent. Ideally, it appears to have solved my message "flooding" concerns, but how can I configure jabberd to operate according to this protocol. Also, are there any issues with just blocking on my message processing loop so that I don't handle any incoming messages before finishing the message I'm currently processing? If I can implement this, the message flooding becomes a non-issue, right?
> > (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?
We're planning on implementing A2A communication between a java-based jabber client app that runs on our web server and a another server-side jabber client C/C++ app. So all interaction over the jabberd transport is strictly within our internal server network. We currently have a jabber client that has built-in message queueing abilities, but we have discovered reliability issues and difficulties in scalability. So we'd like to implement a more simplified client by removing its queue mechanism & extra threading, but this means offloading that process to jabberd -- which seems logical enough since it already has queueing capability. The only issue becomes controlling the flow of messages to client from the queue, which I can only do by blocking within my client's message event loop.
> Peter Saint-Andre
> Jabber Software Foundation
More information about the JDev