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

Ian Paterson ian.paterson at clientside.co.uk
Fri Jul 30 20:55:21 UTC 2004


Peter,

Options 2 and 3 estentially achieve the same thing. I agree #2 (error
stanza) is the best since it does not require a whole new protocol. [Yes,
the connection manager has enough information to return the error as long as
the client includes a 'to' attribute in its JEP-0124 session creation
request (which it should anyway).]

It seems to me that this is essentially a stream level error. But, as I
understand it, XMPP-Core does not allow a 'remote-connection-failed' error
stanza to include the stanza(s) that could not be delivered. :(

I guess we need a new JEP to define the error message a proxy (not just
JEP-0124 proxies) should return to the XMPP server after it fails to deliver
stanzas, and what the server may/should do with the error?

- Ian


Ian wrote:
[large snip - see below]
> > 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.

Peter wrote:
> 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.



> > 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.





More information about the Standards mailing list