Yes that is an interesting usecase for multiple sensors reporting massive amount of data to a server JID, that can have load balancing especially if the server instances are running on different machines.
I don't have enough knowledge of components but shouldn't you really be implementing such load balancing behaviour through a component instead? If the Sever JID has many active resources how is that handled in the clients (the sensors) roster? are all server fullJID's active in the clients roster? will put a lot of pressure on the sensor roster. /joachim *Regards* Joachim Lindborg CTO, systems architect Sustainable Innovation SUST.se Barnhusgatan 3 111 23 Stockholm Email: [email protected] linkedin: http://www.linkedin.com/in/joachimlindborg Tel +46 706-442270 2014-09-11 22:27 GMT+02:00 Steffen Larsen <[email protected]>: > Hi Florian, > > Great stuff. I’ve been talking for the last two year about the same > subject at the summits. For me its always been a wonder that the bare JID > routing is up to the server implementation and that the client have no > understanding or no hinting for setting for it. > So perfect. I really like to contribute to this XEP if you need any help. > Ive been using bare JID routing (all) a lot when doing IoT/M2M on set-top > boxes and over the top second screen implementations. > So count me in!. > > Just a couple of quick fixes: > > * Links in general are missing for the RFC6121. And In section 4.1: > * "Deliver top all ('urn:xmpp:cmr:all’)” should probably be ‘to’ instead > of ‘top’. > > I’ll skim it a couple a more times and will return with some feedback. For > implementation: I will probably implement it in tigase, if I get some more > time. Because I am using bare JID routing all the time - and “hints” is > also a great addition. Although I need to think a bit about what happens > when bringing in offline line AMP etc. :-) > > /Steffen > > On 09 Sep 2014, at 17:14, Florian Schmaus <[email protected]> wrote: > > > I'd like to gather some feedback before I send the XEP to the editors. > > > > The idea behind "Customizable Message Routing" (CMR) originated from a > > Ignite Realtime forum thread [1]: A user asked about Openfire's > > message routing behavior when multiple resources where available and > > if a round-robin distribution of the messages to the resources would > > be possible. He wanted to distribute incoming stanzas, originating > > from sensors, evenly over nodes of a cluster collecting the data from > > the sensors. Every node of the cluster is connected using the same JID > > and has the same priority configured, but with a different resource of > > course. > > > > So we find ourselves in a M2M scenario using XMPP, where many clients > > send their data to one XMPP entity which consists of multiple cluster > > nodes (note that this is *not* a clustered XMPP server). Traditionally > > the XMPP RFCs describe two possible routing algorithms in that case: > > 1. Route to all resources, or 2. Route to the "most available" > > resource. The newer RFC 6121 leaves it to the server implementation > > how to determine the "most available" resource. > > > > That is where CMR jumps in, by exploiting this freedom of RFC 6121 > > e.g. by defining the "most available" resource as the resource chosen > > by a round-robin algorithm. > > > > The XEP of CMR can be found at > > > > https://geekplace.eu/xeps/xep-cmr/xep-cmr.html > > > > and the source is available at > > > > https://github.com/Flowdalic/xeps/tree/master/xep-cmr > > > > I don't consider the CMR specification finished. For example error > > handling is missing in some cases. I also wounder if 5.4 shouldn't go > > into an extra XEP. > > > > Florian > > > > 1: https://community.igniterealtime.org/message/242204 > >
