On Fri, May 25, 2012 at 12:42 PM, Thijs Alkemade <[email protected]> wrote: > > On 20 apr. 2012, at 10:32, Kevin Smith wrote: > >> On Thu, Apr 19, 2012 at 6:01 PM, Matthew Wild <[email protected]> wrote: >>> One solution I came up with was for an entity that relays and archives >>> messages to stamp the message with: <archived by="capulet.lit" >>> id="1234-5678"/> or <archived by="conference.jabber.org" >>> id="8765-4321"/>. I'd be interested in feedback on this idea. >> >> Yes, we need (archiving, rather than stanza) ids stamped on the >> archived stanzas. >> >>> However even <archived/> doesn't cover the case of the client knowing >>> the id of its *outgoing* messages. The server could echo them back >>> with <archived/>... but then things start to get a bit muddy. >>> The alternative is to not solve this, and clients should treat the MAM >>> archive as the canonical source of history - (therefore fetching >>> messages from the archive that have already been sent/received by it). >>> A waste of bandwidth if nothing else. >> >> You will only need to request (assuming you have carbons) on average >> less than a single message that's a duplicate, though - as IM is >> typically send a message/receive a message [yes, there are exceptions >> where this is potentially very untrue], and you will have the id of >> the message you received. >> > > > I've started implementing 0313 in libpurple/Adium, and I think > Matthew explained my concerns quite well. > > Your suggestion assumes that once a client receives an incoming > message from the server, everything the client sent before that > moment was received by the server successfully (it makes sense to > require Carbons to do MAM, but lets assume that Stream Management is > not enabled). Suppose the last session ended with these two > messages, on a high-latency connection which got interrupted: > <snip/> > > If the client thinks message 12345 came before 9876, while the > server thinks it's the other way around, then requesting the archive > from abcde will duplicate message 12345.
Yes. Always requesting based on the uid of the last message that you received will result in receiving from the server duplicates of any messages you have sent since then, and you'll have to not double-store them. 198 means that you know which of your sent stanzas have been processed by the server and does, I think, guarantee your history is complete and you're likely to end up, on average, with ~1 duplicated stanza to deal with on each login. The simple implementation is that you don't store in the cache anything that happened after the last message received from the server - and you know the ordering of your own stanzas vs the stanzas you received based on the ordering of the acks/messages you received from the server. /K
