[ejabberd] Losing messages to dead connections

Holger Weiß 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
  XEP-0184.
- 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 [2]; you
> > might be interested to get in touch with him [3].
> 
> I most definitely want to explore that.

:-)

If you're interested in testing the code and need any help, please let
me know.

Holger (holger at jabber.fu-berlin.de)

¹ See: http://www.process-one.net/en/wiki/ejabberd_events_and_hooks/


More information about the ejabberd mailing list