[Standards-JIG] Re: JEP-0124 HTTP Binding - lost messages

Peter Saint-Andre stpeter at jabber.org
Fri Jul 30 16:10:32 UTC 2004

In article 
<FOENKLDIMCIMONDFDEMKCEHECEAA.ian.paterson at clientside.co.uk>,
 "Ian Paterson" <ian.paterson at clientside.co.uk> wrote:

> A JEP-0124 connection manager may be an independent proxy that makes
> multiple connections to the c2s module of an XMPP server. The following
> scenario shows how messages may be lost:
> The client computer/connection crashes while the connection manager is
> processing a request (i.e. waiting for the XMPP server). If the CM receives
> a message from the XMPP server before it responds to the client then it
> won't be able to send it to the client. If the problem on the client machine
> is persistent (or the client is unable to recover the session ID) then the
> connection manager will end the session and all messages waiting for
> delivery to the client will be lost.
> The best solution is NOT for the CM to store the undelivered message, since
> the user may never try to reconnect via that CM again (e.g. the user may use
> a direct connection instead).
> A better solution might be a new protocol that allowed a message to be sent
> back to the user's server for offline storage or delivery to another
> resource.

I agree that we don't want the connection manager to do offline storage. 
I also agree that it is sub-optimal for stanzas to get lost. It strikes 
me that there are several possible approaches:

1. Connection manager generates an error stanza whose 'to' address is 
the original sender. Not very nice, but the message is not lost.

2. Connection manager generates an error stanza whose 'to' address is 
the server from which it received the message. (Does the connection 
manager have enough information to do this? Probably.) The server can 
then decide whether to send the stanza to offline storage, route the 
stanza to another connected resource, or return an error to the original 
sender. (Remember, offline storage is usually just for message stanzas 
and we will want to return an error for IQs but most likely drop 
presence stanzas.)

3. Develop a new protocol for returning stanzas to the server. This in 
essence is the kind of thing that already exists in the undocumented 
internal protocol used by jabberd 1.x its c2s components (<route/>, 
<error/>, and <log/> elements). There is a good reason why I have never 
documented this protocol, and I don't think this is a good direction to 
go in.

Personally #2 seems good to me.



More information about the Standards mailing list