* Kevin Smith <[email protected]> [2014-05-08 12:34]: > Consider the case of a paused client in a MUC. The MUC sends a > message, and gets a bounce because the buffer's full. The client > resumes the session, but now its out of sync - it thinks its in the > MUC and the MUC has removed it due to bounces.
I can see the point, however I encountered a very similar situation yesterday - even though in the opposite direction: I sent two messages from my client to a MUC, and only the second one arrived. Digging into client and server logs revealed that the first one bounced with the following error: <message id='Tx26a-19' type='error' to='[email protected]' from='[email protected]'> <error type='cancel'><remote-server-not-found xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/> <text xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'> Server-to-server connection failed: DNS resolution failed </text> </error> </message> There was apparently a short network outage between the two servers, causing one of the messages to be bounced, bringing client and MUC out of sync. If the MUC side of this connection had encountered the error, the client probably would have been kicked, leading to what you describe. Furthermore, I am regulary experiencing a MUC-out-of-sync situation when a MUC server is restarted, leading my client to believe it is still in a room where everybody is silent. My point is: we already have a world where things get out of sync because of misbehaving clients, servers, components and networks. Maybe it is better to make this problem explicitly acknowledged instead of feigning an ideal world (this also somehow reminds me of the "TCP is reliable" argument, one layer up). Georg -- || http://op-co.de ++ GCS d--(++) s: a C+++ UL+++ !P L+++ !E W+++ N ++ || gpg: 0x962FD2DE || o? K- w---() O M V? PS+ PE-- Y++ PGP+ t+ 5 R+ || || Ge0rG: euIRCnet || X(+++) tv+ b+(++) DI+++ D- G e++++ h- r++ y? || ++ IRCnet OFTC OPN ||_________________________________________________||
signature.asc
Description: Digital signature
