Dave Cridland <[email protected]> wrote: > you rely on the clients maintaining state.
It would be nice if we could, in fact, rely on clients to maintain state and to do so without error (This is hard to do in XMPP since there is no guarantee of message delivery...), however, while this relying on state-full clients is an attractive idea, it is likely that in many cases, we simply can't generally make this assumption. Other than the limitations of the XMPP protocol itself (i.e. no delivery guarantee), we also need to recognize that we're seeing significant growth in the use of clients that don't have a great deal of long-term storage capacity -- i.e. mobile phones, tablets, etc. Thus, in any case, "last mile" delivery of messages will need to support delivery of all data that might be needed by the client in order to do whatever it is that it does with new messages. (Yes, we can reduce the client's to simply be display devices for state maintained on intermediary servers, but this is not, I think, ideal.) A reliance on clients' maintaining state would also seem to assume that a reasonably high percentage of the traffic shares message-independent "static" information with messages received earlier and thus that cache-hit rates are reasonably high. Client maintenance of state is most useful when all messages have the same originator. It is least useful when every message has a unique sender. Today, most applications relevant to this discussion only support "topic-based" publish/subscribe. Thus, they implement what we tend to call "follow" -- messages will be received from some whitelisted set of publishers. However, in the future, I'm fairly confident that we'll see an increase in the number of systems that support "content-based" publish and subscribe. Thus, we'll see messages being delivered because of their content, not simply because of their author. This sort of thing will be very much like the "Track" function that originally influenced, in part, Twitter's adoption of "Atom over XMPP". In the "Track" use case, (when you might subscribe to all messages containing the keyword "XMPP") you'll often get messages from senders that you've never seen before or will never see again. Thus, you'll often find that cache hit rates are lower than you'd like even though you may dedicate a great deal of resource to maintaining that cache. So, we see that, at least, limitations in the XMPP protocol, resource limitations on the clients, and a move towards cache-inefficient content-based routing all tend to argue against an assumption that we can rely on clients to maintain state... bob wyman On Fri, Apr 30, 2010 at 1:00 PM, Dave Cridland <[email protected]> wrote: > On Fri Apr 30 17:26:16 2010, Bob Wyman wrote: > >> Please do not regress to the old, now largely deprecated, light >> pinging/notification model. That stuff works great in small systems or in >> prototype demonstrations, but it is a real mistake for any system that >> expects to experience successful growth. >> > > I agree that if you have a case where information is demanded on every > notification, then yes, you will end up with a thundering herd problem as > the majority of subscribers stampede to get the same additional information > they seek at once. > > But please, credit me with at least half a brain cell. > > XEP-0115 and PEP already interact such that notifications contain the > information that has changed, and that is interesting to the client. > > So, in this instance, instead of sending out full profile, geoloc, full > name, profile statement, and favourite colour information with every notice, > then you'd send such information out individually when it itself had changed > - if clients expressed an interest in it. In other words, you rely on the > clients maintaining state. If the state is, for some reason, lost or > unavailable, then in this case an explicit request is indeed made, but this > is triggered not by a notification, but by client-specific circumstances, > and therefore does not yield a thundering herd. > > The XMPP community is already deploying such mechanisms out in the real > world on substantial scale, and it works just fine, by the way. > > > Dave. > -- > Dave Cridland - mailto:[email protected] - > xmpp:[email protected]<xmpp%[email protected]> > - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ > - http://dave.cridland.net/ > Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade >
