[ejabberd] Losing messages to dead connections

Raoul Duke rduke496 at gmail.com
Mon Mar 24 15:17:20 MSK 2014


On Mon, Mar 24, 2014 at 6:34 AM, Konstantin Khomoutov
<flatworm at users.sourceforge.net> wrote:
> On Sat, 22 Mar 2014 18:32:44 +0000
> Raoul Duke <rduke496 at gmail.com> wrote:
>
> [...]
>>
>> The issue with mod_ping however, as the above post also points out, is
>> that the 32 second timeout for receiving pongs is quite long in the
>> context of this message black-holing problem.  I would like to lower
>> the window of potentially black-holed messages.  Am I correct in
>> assuming that this is the best I can do (in lieu of something like
>> xep-0198?).
>
> You might consider using [1] "Message Delivery Receipts" -- it's
> client-only message delivery acknowledgement mechanism.  The upside
> is that no server-side support is required; the downside is that
> each message stanza sent produces another one coming back which is
> bandwidth wasting.  And of course, in order for this to work, both
> clients have to support this extension.

I am using MDR but what I think I see here (in the context of the
recipient being a black-hole connection) is that to the sender it
looks like the message was sent but never read but to the receiver it
looks like the message was never received.  So unless I'm missing
something it doesn't help me with my core problem, i.e. that the
receipient never received the message and the sender doesn't know
that.  Is there some way I can use MDR to help solve that problem?  If
so: how would I tell the difference between the 2 scenarios: "user has
not received the message" and "user has not read the message"?

> [...]
>> "I created a mod and hooked up to the send_packet and receive_packet
>> events. Save the message ID to a table. Start a 10 sec waiting thread.
>> If the receive_packet hook gets the message ID back under 10 sec I
>> kill the thread, else I manually store the message in the offline
>> table. Worst case now is, I might have the msg twice in the offline
>> table. But it will have the same ID, our clients know not to duplicate
>> messages. - Johan Vorster Dec 12 '13 at 16:49"
>>
>> This sounds like a bit of a kludge but it also sounds like it may be
>> an effective one.  Does this sound viable?  Does anyone know or have
>> any mod already implemented like this?  It isn't clear to me in the
>> user_receive_packet how I could interrogate the MessageID, can someone
>> send me a pointer/example of this?
> [...]
>
> I'd say this is really a kludge: the user might legitimately not send
> any messages for more than 10 seconds.  Or do you mean this kludge is
> supposed to work along with mod_ping thus forcing a lower timeout?

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

If it is the latter it seems like the proposed module doesn't actually
accomplish anything.  Or do you see it otherwise?

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

Thanks for the pointers.


More information about the ejabberd mailing list