FASTer connections for Openfire!

Blogs Ignite Realtime Blogs
, ,
1

On mobile (and worse), baseline XMPP is a little more painful than it should be. It has a lot of round-trips, where the client sends a request and waits - patiently - for the answer before it can continue.

Baseline XMPP actually has 9 of these before you can send and receive messages, and while Openfire has dropped some of these for a while (we’ve supported Direct TLS, for clients, for ever), others haven’t yet made it here. Silly, as I wrote SASL2 some time ago, which is a framework for amortising some of the start-up requests into the authentication.

Others are Bind2 - which pulls resource binding into SASL2 and also allows multiple other “connection setup” things to work - and FAST, which hands out tokens to allow reauthentication which is, well, FAST. This gets us down to 4 round-trips - halving connection time.

Thanks to a supporting grant from the NLNet Foundation, these are now all in our “main” branch, and undergoing their final testing before we make a release, so will be in our nightly builds from now on. I’ve been lucky enough to spend three weeks doing (sometimes literal!) field testing over slow links, so I’ve seen first hand that fortune really favours the bold with these extensions.

We’ve also improved security, with Channel Bindings and Downgrade Protection - also in the nightlies, and added new SCRAM variants like SCRAM-SHA-512-PLUS. Sorry Alexey, we’ve not done the SHA3 variant quite yet, but our FAST implementation does support the new HT2-* family, including the HT2-SHA3- variants.

We even found another round-trip to save, with Initial Authentication Pipelining.

There is also supporting work to make all this happen - like improvements to message archiving, and improvements to our sister project, the XMPP Interop Testing framework, so we can do live testing. This is based on Smack, so that, too now has SASL2, Bind2, and FAST support in its latest Alpha release, 4.6.0-alpha1.

We’d welcome people trying this code out - it’s a lot of exciting new features, and should be highly beneficial to most users of Openfire, and indeed client developers using Smack. It’s still nightlies, not releases, but we’re keen to move this forward as, erm, FAST as we can.

Yeah, I’m not even sorry.

For other release announcements and news follow us on Mastodon or X

3 Likes
2

As usual, it has been fun working with you and Dan on this over the past few months. The NLnet-funded work turned into one of those projects that ripples further than you’d expect. We didn’t just add SASL2/FAST/Bind2 support to Openfire; testing it properly meant extending the XMPP Interop Testing framework, and that meant Smack needed the same functionality. Thanks to Florian for adding it there. So one grant ended up leveling up three projects at once: Openfire, Smack, and Interop Testing.

For Openfire admins specifically: this isn’t just theory. We’ve been running it on the servers behind igniterealtime.org for a while now, with a range of clients (including several third-party ones) in daily use, and it’s held up really well.

If you’re running Openfire, grab a nightly build and give it a try. Especially if you or your users are on mobile or flaky connections, since that’s exactly where SASL2/FAST/Bind2 pay off most. Client developers can try it against Smack’s new 4.6.0-alpha1 release too.

We’d love to hear how it goes, good or bad. Feedback and bug reports are very welcome. I wrote up a bit more on the interop-testing side of this if you want the other angle: Next-Gen Connectivity