[ejabberd] Losing messages to dead connections
holger at zedat.fu-berlin.de
Tue Mar 25 00:00:21 MSK 2014
* Raoul Duke <rduke496 at gmail.com> [2014-03-24 11:17]:
> The meaning I extracted from the idea posted by Johan Vorster was that
> he would have a mod_something which registers for user_send_packet and
> user_receive_packet callbacks. When user X sends a message, ejabberd
> would fire the user_send_packet callback in the extension/module, in
> which case he would copy the message to a queue (keyed on the Message
> ID), start a timer for 10 seconds and if user Y (the recipient)
> collects it within 10 seconds there would be a user_receive_packet
> callback fired and he would assume the message was delivered. If he
> does not get a user_receive_packet callback for the given messageID
> within 10 seconds then he would assume the user had gone away and copy
> the message from the queue to the offline store (therefore assuming it
> may not have been delivered).
> Having written that I'm actually not sure if his idea actually would
> work in practice, but I hope you can advise. Is user_receive_packet
> an event which states that the user received the message or is it just
> an event which means "we think we sent the user a message but (re: the
> general context of this thread) we might have sent it to a blackhole".
It's the latter: "user_receive_packet" is triggered when ejabberd
_sends_ a stanza to a local client.¹ There's no event that indicates a
client actually _received_ a stanza, as right now, ejabberd simply
doesn't notice when this happens (which is precisely the issue the
module attempts to address).
> If it is the latter it seems like the proposed module doesn't actually
> accomplish anything. Or do you see it otherwise?
The module is meant to be used on top of XEP-0184. Basically, it keeps
track of the messages sent by a client and resends them if no XEP-0184
acknowledgement was received within 10 seconds. Some issues I see are:
- Obviously, the module only works if both clients involved implement
- The module might produce (a potentially large number of) duplicates if
the client doesn't weed them out.
- Creating a new process for each and every message is not exactly
efficient. Erlang processes are cheap, but not free.
- The code posted on Stack Overflow attempts to write unacknowledged
messages to offline storage (in addition to resending them) without
checking whether the recipient is actually on the local server. This
could be fixed by simply swapping the handlers for "user_send_packet"
and "user_receive_packet" (so that message delivery is checked on the
receiving side instead of on the sending side), though.
This first issue would be a showstopper for me. It sounds like the
author of the module has control over the clients, which I don't; so the
situation is different for him.
> > Holger Weiss is working on implementing XEP-0198 for ejabberd ; you
> > might be interested to get in touch with him .
> I most definitely want to explore that.
If you're interested in testing the code and need any help, please let
Holger (holger at jabber.fu-berlin.de)
¹ See: http://www.process-one.net/en/wiki/ejabberd_events_and_hooks/
More information about the ejabberd