Wed, 11 Oct 2017 19:14:31 +0200 Georg Lukas <ge...@op-co.de> wrote: > Contra: not cloud-scale, because it requires a global lock when a > client reconnects. However, a global lookup table is needed anyway to > enumerate all resource of a client for presence / bare-JID routing.
I already replied in xsf@ chatroom, I'd like to clarify here why I think per-resource inter-node routing doesn't work as expected (at least in my practice): You need to know all user's connected resources in a lot of places: routing messages to bare jids, routing subscriptions, routing roster pushes, routing blocking commands, admin commands, etc. One may argue that you can just broadcast (or use gossip/epidemic routing) to all nodes, but in fact it's much more efficient to broadcast a c2s session pointer/record at all nodes only once (on login) or twice (on logout) in order to keep the "c2s" table replicated on all nodes instead of doing this indefinite amount of times (this will depend on use case). Or you can use internal cache in front of the global table in a database such as SQL/Redis/etc. This will still be more efficient in my opinion. For example, ejabberd uses both approaches depending on a database you choose to store sessions. Another issue with broadcasting is offline messages (we need to eliminate them to make it work) and per-priority routing (no idea how to solve this with broadcasting). Of course, it's possible to use broadcasting if the underlying XMPP routing protocol is changed, but I'm not sure we want to go this route because some complexity will be put on clients. Hope I was clear ;) _______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
