Search code examples
xmppejabberd

Real time data streaming in xmpp ejabberd

I am configuring an ejabberd xmpp server for remote streaming of real-time graph data. The implementation is successful, but now a lot of performance issues are cropping up.

My requirement is to send around 3000 messages per minute into a mobile network through ejabberd-xmpp and receive it in a desktop application without any considerable delay.

I have altered traffic_shapers in the ejabberd.yml configuration file to very large values and have modified a lot of other traffic limitations and yet a large amount of buffering is happening on the desktop side when tested in low bandwidth.

So, if I am positive that my configuration is correct, what all extensions should be used? In the time I have researched I have found that the following XEP's can be of help:

    Stream Compression(XEP-138)
    Jingle ICE-UDP Transport Method(XEP-176)
    Bidirectional-streams Over Synchronous HTTP (BOSH)(XEP-124)
    XMPP Over BOSH(XEP-206)
    Stream Management(XEP-198)

But all the research has only increased the number of doubts:

    If I am to implement any of these XEP's, then what all changes to the configuration have to be made?
    How will I have to alter my XML stanza accordingly? The XEP documentations are surprisingly inadequate for a rookie.
    What is the difference between Stream Management and Stream Compression?
    What is the difference between XMPP Over BOSH and Bidirectional-streams Over Synchronous HTTP?
    How to implement BOSH? I am using port number 5222 now, what all changes to my project will come if I use port 5280? Where all should I reflect these changes?
    If I am to combine any two extensions, will it only increase the speed issue or will it be in my favour?

Please, if anybody can help? I do realize that this question is out of the question spectrum that can be posted on this site and also as the guidelines specify, 'out of scope' and 'off topic'. But any help will be immensely appreciated. Thanks in advance!

Solution

  • The issue is with the negotiation order followed by Ejabberd. Ejabberd follows stream negotiation in this order:

    -TLS
    -Stream Compression
    -SASL
    -Resource Binding

     whilst all the other clients and libraries follow the Recommended Order for Stream Negotiation XEP-170:

    -TLS
    -SASL
    -Stream Compression
    -Resource Binding

     This leads to the <compress> request to be completely ignored by the ejabberd server after SASL encryption. Since the XEP-170 is identified by the XMPP document keyword RECOMMENDED and not REQUIRED, there is no strict enforcement
    Although the supported protocols here specify that XEP-170 is followed, but I feel that the issue from this link which says that "ejabberd 1.1.2: It only accepts compression before SASL (XEP-0138)" is still not fixed
    (Tested the same scenario with OpenFire 3.10, XIFF AS3 library and Seesmic-XMPP AS3 library and compression was happening since OpenFire allows compression before OR after SASL encryption)