Project

General

Profile

Connection time optimizations

Igor Khomenko
Added over 3 years ago

Is it possible to optimise the connection time to Tigase?

The main concerns described here

http://stackoverflow.com/questions/23775801/xmpp-connection-time-optimization

https://blog.hipchat.com/2012/10/26/performance-tuning-ios-making-mobile-fast/

For now the end user has to do about 6 back-and-forth round trips

Does Tigase provide some kind of ways to speed up this?


Replies (15)

Avatar?id=6023&size=32x32

Added by Artur Hefczyc TigaseTeam over 3 years ago

I suggest to use stream management extension specifically stream resumption feature. So your first login would be normal but subsequent reconnects could be much faster.

Added by Igor Khomenko over 3 years ago

Thanks Artur,

This can work great on the desktop environment,

but I have some concerns about mobile, especially iOS

iOS doesn't support the 'true' background mode, so we can't have the persistent connection to the server.

The recommended way is to close connection when user goes to the background or close an app.

So every time a user opens an app we should do fresh XMPP connect, following all these round-trips

Avatar?id=6023&size=32x32

Added by Artur Hefczyc TigaseTeam over 3 years ago

I still think, even for mobile devices you can use stream management and stream resumption. My assumption is that, if a user uses the app 1 or 2 times a day, than it is not that big of an issue that the login takes a bit longer. The problem affects only users who use the app several times an hour and they have wait that long every time they open the app. If this is the case, I would just use stream resumption. You could configure Tigase to timeout stream resumption after 1h for example. If user reconnects within 1 hour, it would be quick reconnect. Otherwise it takes longer time.

Added by Igor Khomenko almost 3 years ago

Hi again there,

I'm back now to this question and we are still not satisfied with the standard XMPP login logic/duration.

I just did a quick research and found some interesting links:

It's definitely a room for the improvements. All modern chat apps like WhatsApp, Viber connect really fast.

Do you have any visibility on this, will it be easily possible for Tigase community to minimise all needed roundtrips via code customizations or it's too hard to do it from the architecture point of view?

Avatar?id=6023&size=32x32

Added by Artur Hefczyc TigaseTeam almost 3 years ago

Igor Khomenko wrote:

Hi again there,

I'm back now to this question and we are still not satisfied with the standard XMPP login logic/duration.

Did you try our suggestion to use stream management as suggested above. With long stream management timeouts on the server side this would give you the fastest possible reconnection time. I do not know WhatsApp or Viber implementation details but I believe they must use something similar to ensure both fast and secure reconnection.

I just did a quick research and found some interesting links:

This looks promising but I do not think the XEP is well thought through. The idea is good and with some modifications and polishing it should improve login time. I am not sure, however, how significant this improvement would be.

I think you are mistaken with this one, the information on the page is a bit misleading. The page describes only user authentication part of the user login, not the entire login handshaking. I really do not see anything "quick" on there. These 2 round trips for authentication is actually a typical exchange for SASL or non-SASL authentication. After and before authentication there is some more, time consuming, handshaking necessary. The XEP above attempts to address is, I mean the whole login process. But, really nothing can be as quick as stream management reconnection because it bypasses all the login handshaking.

It's definitely a room for the improvements. All modern chat apps like WhatsApp, Viber connect really fast.

Comments given above.

Do you have any visibility on this, will it be easily possible for Tigase community to minimise all needed roundtrips via code customizations or it's too hard to do it from the architecture point of view?

After 3 years adoption of the mentioned XEP is minimal and I think the reason for this is rather insignificant improvement it provides. I agree there is a room for improvement and the login should/could be much faster but I think the right direction is to work on the stream management improvements (spec and implementation) to make it more useful and provide a way to quickly reconnect for mobile devices.

Added by Igor Khomenko almost 3 years ago

Thanks Artur,

I found one thing which we can actually omit:

If your server is new enough (so implements RFC 6121 correctly), you can skip a roundtrip by skipping the urn:ietf:params:xml:ns:xmpp-session IQ. 

See https://datatracker.ietf.org/doc/draft-cridland-xmpp-session/?include_text=1.
The Extensible Messaging and Presence Protocol (XMPP) historically had a Session Establishment request defined in RFC 3921 which clients were required to perform at the beginning of a session. RFC 6121 dropped this entirely. This specification reinstates it as an optional no-op to aid backwards compability, matching commonly deployed workarounds.

and this is also mentioned here https://tools.ietf.org/html/rfc6121#page-112

Can we skip this step with Tigase?

Avatar?id=6023&size=32x32

Added by Artur Hefczyc TigaseTeam almost 3 years ago

As a matter of fact you can. Tigase has always been allowing to skip the step, even during the RFC 3921 time.

Added by Steffen Larsen almost 3 years ago

Interesting Artur. Is it enabled per default or can it be enabled in the property file?

Added by Wojciech Kapcia TigaseTeam almost 3 years ago

It's "enabled" by default, i.e. it was never mandatory and simply advertised as possible in the stream futures.

Added by Igor Khomenko almost 3 years ago

I have found that Smack Java client deals with it in a different way

https://igniterealtime.org/issues/browse/SMACK-622

they use this document http://tools.ietf.org/html/draft-cridland-xmpp-session-01

with 'optional' marker.

do you have any view on it?

Added by Wojciech Kapcia TigaseTeam almost 3 years ago

Well, rationale behind it sounds solid and could help with compatibility (especially if you can't influence client behaviour). I've created #3918 and added you to the watchers.

Added by Igor Khomenko almost 3 years ago

Another thing that can be optimised is to cache DNS lookup results and connect via IP to server, so we can bypass the DNS lookup request on each login.

This can save some time.

Do you have any view on this, for example, maybe you have some login in your JAXMPP library

Avatar?id=6098&size=32x32

Added by Bartosz Malkowski TigaseTeam almost 3 years ago

There is no DNS cache in jaxmpp but it may be added in two ways:

  1. by us, by modify jaxmpp code

  2. by you, by add custom DnsResolver:

UniversalFactory.setSpi(DnsResolver.class.getName(), new UniversalFactory.FactorySpi<DnsResolver>() {
    @Override
    public DnsResolver create() {
        return yourImplementationOfDnsResolver;
    }
});

You have to register it before you create Jaxmpp instance.

Added by Igor Khomenko almost 3 years ago

Thanks, it's clear.

I have another idea,

let's say we have the following set of requests/responses:

1) SEND: <stream:stream to='chat.myserver.com' xmlns:stream='http://etherx.jabber.org/streams' xmlns='jabber:client' xml:lang='en' version='1.0'>
2) RECV: <stream:stream version="1.0" from="chat.myserver.com" id="c26e4662-f85f-4cc5-9c5e-35063c1d7eed" xml:lang="en">
3) RECV: <stream:features xmlns="http://etherx.jabber.org/streams"><sm xmlns="urn:xmpp:sm:3" /><mechanisms xmlns="urn:ietf:params:xml:ns:xmpp-sasl"><mechanism>PLAIN</mechanism><mechanism>ANONYMOUS</mechanism></mechanisms><ver xmlns="urn:xmpp:features:rosterver" /><starttls xmlns="urn:ietf:params:xml:ns:xmpp-tls" /><compression xmlns="http://jabber.org/features/compress"><method>zlib</method></compression></stream:features>
4) SEND: <starttls xmlns="urn:ietf:params:xml:ns:xmpp-tls" />
5) RECV: <proceed xmlns="urn:ietf:params:xml:ns:xmpp-tls" />

6) SEND: <stream:stream to='chat.myserver.com' xmlns:stream='http://etherx.jabber.org/streams' xmlns='jabber:client' xml:lang='en' version='1.0'>
7) RECV: <stream:stream version="1.0" from="chat.myserver.com" id="c26e4662-f85f-4cc5-9c5e-35063c1d7eed" xml:lang="en">
8) RECV: <stream:features xmlns="http://etherx.jabber.org/streams"><sm xmlns="urn:xmpp:sm:3" /><mechanisms xmlns="urn:ietf:params:xml:ns:xmpp-sasl"><mechanism>PLAIN</mechanism><mechanism>ANONYMOUS</mechanism></mechanisms><ver xmlns="urn:xmpp:features:rosterver" /><compression xmlns="http://jabber.org/features/compress"><method>zlib</method></compression></stream:features>
9) SEND: <auth xmlns="urn:ietf:params:xml:ns:xmpp-sasl" mechanism="PLAIN">AD2xNz3yMTg3OTIA3aWdvcnF1aW3rYm3veDcxQ==</auth>
10) RECV: <success xmlns="urn:ietf:params:xml:ns:xmpp-sasl" />

11) SEND: <stream:stream to='chat.myserver.com' xmlns:stream='http://etherx.jabber.org/streams' xmlns='jabber:client' xml:lang='en' version='1.0'>
12) RECV: <stream:stream version="1.0" from="chat.myserver.com" id="c26e4662-f85f-4cc5-9c5e-35063c1d7eed" xml:lang="en">
13) RECV: <stream:features xmlns="http://etherx.jabber.org/streams"><sm xmlns="urn:xmpp:sm:3" /><mobile xmlns="http://tigase.org/protocol/mobile#v3" /><ver xmlns="urn:xmpp:features:rosterver" /><compression xmlns="http://jabber.org/features/compress"><method>zlib</method></compression><bind xmlns="urn:ietf:params:xml:ns:xmpp-bind" /><session xmlns="urn:ietf:params:xml:ns:xmpp-session" /></stream:features>
14) SEND: <iq type="set" id="a4805eaa-9953-4d5b-a893-652546cac328-1"><bind xmlns="urn:ietf:params:xml:ns:xmpp-bind" /></iq>
15) RECV: <iq to="5179218-92@chat.myserver.com/1220770403-myserver-275712" type="result" id="a4805eaa-9953-4d5b-a893-652546cac328-1"><bind xmlns="urn:ietf:params:xml:ns:xmpp-bind"><jid>517921892@chat.myserver.com/1220770403-myserver-275712</jid></bind></iq>

If we know that we will use the PLAIN auth and resource binding feature, can we skip 6-8 and 11-13 steps on a client side?

can we just send the auth request right after the 5th step?

Added by Andrzej Wójcik IoT 1 CloudTigaseTeam almost 3 years ago

I think this will not work good as it will not make this XMPP stream correct as defined in XMPP RFC, where XMPP RFC requires steps you want to omit.

About this "speeding up" of connection time, there is already a XEP for this - XEP-0305: XMPP Quickstart . This XEP is not yet supported by Tigase XMPP Server but we have plans to implement this feature - see #1936

    (1-15/15)