[ejabberd] some points last version

ricky gutierrez xserverlinux at gmail.com
Thu Feb 5 01:07:39 MSK 2015


2015-02-02 15:29 GMT-06:00 Holger Weiß <holger at zedat.fu-berlin.de>:
> As these questions pop up quite frequently these days, I've put together
> a text that tries to explains this stuff.  It's meant to be published
> online somewhere.  Please let us know it if anything remains unclear.
> It's a bit long-ish, so I'm also open to suggestions on how it could be
> shortened!
>
> ---------- 8< -------------------------------------------- 8< ----------
>
> # Dead connections, message loss, and outdated presence
>
> ## What's the issue?
>
> An XMPP client talks to ejabberd using a TCP connection.  Such a
> connection can get "lost" without being properly closed.  This can
> easily happen when clients on mobile or wireless networks loose their
> connectivity.  In such a situation, the connection will appear as open
> to ejabberd until a TCP timeout is reached, which might take several
> minutes or hours (depending on the operating system configuration).
> During that time, ejabberd will happily continue sending messages to the
> client, as the server won't be notified of the issue.  XMPP wasn't
> designed with such unreliable (mobile) connections in mind, so the
> original standard provides no mechanisms to deal with this issue.
> Therefore, those messages are lost.

I understand this point, although the new fashion is all in the mobiles :(

>
> ## How to detect a dead connection?
>
> One way to detect a dead connection is to ping the client periodically
> and to kill the connection if the client doesn't respond.  This can be
> done using [`mod_ping`][1].  However, these ping packets might wake up
> the client's radio, so a short ping interval might drain mobile
> batteries.  Therefore, it's not generally recommended to use an interval
> of less than a few minutes.  Either way, there's always _some_ time
> window where messages can be lost.

inside of my ejabberd.yml I have the mod ping enabled

 mod_ping:
    send_pings: true
    ping_interval: 60
    timeout_action: kill

>
> ## So how to deal with a dead connection?
>
> ejabberd 14.05 and newer support an XMPP extension called "Stream
> Management" which is meant to deal with the short outages that are
> common on mobile networks.  This extension lets both the client and the
> server request message acknowledgements.  It also allows clients to
> resume sessions when they come back online after they lost connectivity.
> Any messages that weren't delivered over the previous connection are
> retransmitted during session resumption, so message loss no longer
> occurs.
>
in this part I'm trying this option

    stream_management: true
    resend_on_timeout: if_offline
    resume_timeout: 60


> ## What happens if session resumption fails?
>
> By default, even if ejabberd _does_ detect a dead connection (e.g., by
> means of [`mod_ping`][1]), it keeps the session open for a few minutes
> to give the client a chance to resume the session.  During that time,
> the client will necessarily appear as online to its peers even though
> it's not.  In most cases, the client resumes the session within that
> time frame.  But if it doesn't, ejabberd will by default bounce error
> messages for any unacknowledged messages back to the sender.
>
> ## Why aren't unacknowledged messages written to offline storage?
>
> ejabberd can be configured to _resend_ unacknowledged messages instead
> of generating error bounces by setting `resend_on_timeout: true` in the
> `ejabberd_c2s` [listener configuration][2].  If no other client of the
> recipient is online and [`mod_offline`][3] is enabled, they will end up
> in offline storage.  But if another client _is_ online, that client will
> receive those messages.  The problem is that the same client might've
> _already_ received copies of those messages some minutes earlier (if
> they were sent to the bare JID and he had the same priority as the
> now-offline client, or if [carbon copies][4] were enabled).  Receiving
> another copy of a bunch of messages is not what users would expect, so
> this setting is only recommended to admins who _know_ their server is
> not going to be used that way.


let me know something, carbon copy enabled by default?

>
> ejabberd 14.12 and newer also supports setting `resend_on_timeout` to
> `if_offline`, which means those messages are going to be resent (to
> offline storage) only if no other client is online when the timeout
> occurs.  Otherwise, error messages are bounced.  In many (but not all)
> situations, this does what users want.
>
> ## How to disable that Stream Management stuff?
>
> To disable the Stream Management features described above, just set
> `stream_management: false` in the `ejabberd_c2s` [listener
> configuration][2].
>

direct question!, if you had this scenario in most of your users what
would be your best configuration?

another question, ejabberd can announce when a user is initiating
session , would be an excellent feature! , maybe on roadmap



-- 
rickygm

http://gnuforever.homelinux.com


More information about the ejabberd mailing list