<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 12 May 2014 08:05, Georg Lukas <span dir="ltr"><<a href="mailto:georg@op-co.de" target="_blank">georg@op-co.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

* Kevin Smith <<a href="mailto:kevin@kismith.co.uk" target="_blank">kevin@kismith.co.uk</a>> [2014-05-08 12:34]:<br>
<div>> Consider the case of a paused client in a MUC. The MUC sends a<br>
> message, and gets a bounce because the buffer's full. The client<br>
> resumes the session, but now its out of sync - it thinks its in the<br>
> MUC and the MUC has removed it due to bounces.<br>
<br>
</div>I can see the point, however I encountered a very similar situation<br>
yesterday - even though in the opposite direction: I sent two messages<br>
from my client to a MUC, and only the second one arrived. Digging into<br>
client and server logs revealed that the first one bounced with the<br>
following error:<br>
<br>
<message id='Tx26a-19' type='error' to='<a href="mailto:jid@op-co.de" target="_blank">jid@op-co.de</a>' from='<a href="mailto:yaxim@chat.yax.im" target="_blank">yaxim@chat.yax.im</a>'><br>

  <error type='cancel'><remote-server-not-found xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/><br>
    <text xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'><br>
      Server-to-server connection failed: DNS resolution failed<br>
    </text><br>
  </error><br>
</message><br>
<br>
There was apparently a short network outage between the two servers,<br>
causing one of the messages to be bounced, bringing client and MUC out<br>
of sync. If the MUC side of this connection had encountered the error,<br>
the client probably would have been kicked, leading to what you<br>
describe.<br>
<br></blockquote><div><br></div><div>I'm not sure we discuss what clients should do if they receive an error "from" the MUC. We should probably give some advice there. I suspect we should assume the client is no longer in the MUC, but that assumption is only really safe if the MUC is handling joins properly.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

Furthermore, I am regulary experiencing a MUC-out-of-sync situation when<br>
a MUC server is restarted, leading my client to believe it is still in<br>
a room where everybody is silent.<br>
<br></blockquote><div><br></div><div>Then the server isn't M-Link, because I fixed that case. Usually, though, that's when you join a room that thinks you're in it already, rather than the other way around - I used to get this a lot when restarting my personal (and often development) server, which is why I spent a silly amount of time fixing it.</div>
<div><br></div><div>The problem then is that some servers treat the join (marked specifically as a join) as updated room presence, and don't hand back the list of occupants, etc.</div><div><br></div><div>If the MUC thinks you're not in the room, and your client thinks it is, then the MUC treats an updated presence as a groupchat (ie, pre-XEP-0045) join, and your client just has to notice the presence and history. This is slightly unpleasant, but the user experience is a lot less confusing.</div>

<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
My point is: we already have a world where things get out of sync<br>
because of misbehaving clients, servers, components and networks. Maybe<br>
it is better to make this problem explicitly acknowledged instead of<br>
feigning an ideal world (this also somehow reminds me of the "TCP is<br>
reliable" argument, one layer up).<br>
<div><div><br></div></div></blockquote><div><br></div><div>The point of 198 is to reduce the scope of this.</div><div><br></div><div>TCP *is* reliable, within bounds. 198 makes XMPP reliable within a larger scope.</div>
<div><br></div><div>On a grander scale, we can look for cases where state is held in common by multiple entities, and see how to avoid mismatch - the MUC joined state example above is one case, but there are others (pubsub and presence subscriptions, etc).</div>
<div><br></div><div>Dave.</div></div></div></div>