Addendum: As Zash pointed out[1], this is documented behavior for offline messages, i.e. messages send while the user was offline. Those are only send if the user announced availability via a presence or if XEP-13: Flexible Offline Message Retrieval is used. This is to prevent storms of offline messages when the client (re-)connects.
But it's certainly not true that you "won't receive any message despite ... successful connection".
Indeed, my description was rough and from memories a few year ago. But I believe it still demonstrates the point I was trying to illustrate:
There is unneccessary complex behaviour in XMPP that you must write extra code in your client for. Otherwise it will work mostly, but not always and not reliably.
Pretty sure you want your XMPP client to announce that it is online, so you'd have to implement that anyways.
This is all well described in the RFCs and http://www.xmpp.org/extensions/xep-0160.html
IIRC, the ejabberd server will wait until you are "present". Only then it will send you all messages so far received for you.
Re:XMPP Myths
by davecridland on Tuesday August 11, 2015 @11:04AM
(#10041569)
Really? The old Google Talk service used to do this, but I didn't think ejabberd did. There's a bunch of non-IM use-cases which need presence-less messaging.
That ejabberd does something doesn't mean it's the proper behaviour. Maybe it's a bug?
That statement is wrong. Sending an initial presence merely indicates your availability to entities subscribed to your presence. Not sending the initial presence does not prevent you from receiving message stanzas.