"Peter Saint-Andre" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > 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 > > -- > Peter Saint-Andre > Jabber Software Foundation > http://www.jabber.org/people/stpeter.php _______________________________________________ jdev mailing list [EMAIL PROTECTED] https://jabberstudio.org/mailman/listinfo/jdev
