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 _______________________________________________ jdev mailing list [EMAIL PROTECTED] https://jabberstudio.org/mailman/listinfo/jdev
