powered by Jive Software

Smack and Websockets

Hello everybody

I have a couple of questions regarding Smack and web sockets.

Some background info:
We are currently using smack-bosh (version 4.3.1) to connect to Cisco Finesse using XMPP BOSH (with http-bind). In a future version Finesse will stop supporting BOSH and web sockets will need to be used instead.

Now to the questions:

  • Am I correct that smack starts supporting web sockets as of version 4.5.0?
  • If yes, when will this officially be released? Are there any plans on this yet? I see that at the moment there is a version 4.5.0-alpha1. I assume it’s not safe to use that in production code?

Thanks a lot for your replies.

Yes, that is correct.

No, there are not plans. I am quite busy this year, so unless something motivates me to cut out a release, there isn’t one planned this year. I currently consider a release in the first half of 2023, but needless to say, there is no guarantee for that.

That assumption is more or less wrong. It’s in the alpha stage because, as far as I can tell, it hasn’t seen much use. It could be working perfectly fine. Nothing really makes a release version much different from a alpha version (at least in Smack’s case). Usually, at some point it was just decided that now enough time has passed for a release, mostly without me having had much feedback about the pre-release versions. I feel that what then happens is that, understandably, people start to use the first version of a release, say Smack 4.4.0, and only then the bug reports start to roll in. I guess if you want to use a really “stable” version, then you may could consider waiting for a release with a high patchlevel version number, say Smack 4.4.6. :slight_smile:

However, it would help me¹ as Smack maintainer and developer if people where using alpha/beta versions — I actually feel like we could switch from alpha to beta for Smack 4.5 now — in staging environments, and report back their findings. Be they positive or negative.

1: I believe this applies to ther project maintainers too

@Flow , thanks a lot for your response.

So I managed to connect to our server using an approach similiar to what is done here.

Here’s the code, might be useful for other people trying this out too. :wink:

String xmppDomain = "finesse.mycompany.com";

ModularXmppClientToServerConnectionConfiguration.Builder builder = ModularXmppClientToServerConnectionConfiguration.builder();
builder.removeAllModules()
   .setXmppDomain(xmppDomain)
   .setSendPresence(true)
   .setHost(xmppDomain)
   .setSecurityMode(ConnectionConfiguration.SecurityMode.required)
   .setUsernameAndPassword(user.getLogin(), user.getPwd());

XmppWebSocketTransportModuleDescriptor.Builder websocketBuilder = XmppWebSocketTransportModuleDescriptor.getBuilder(builder);
websocketBuilder.explicitlySetWebSocketEndpointAndDiscovery("wss://" + xmppDomain + ":8445/ws/", true);
builder.addModule(websocketBuilder.build());
ModularXmppClientToServerConnectionConfiguration config = builder.build();

ModularXmppClientToServerConnection connection = new ModularXmppClientToServerConnection(config);
connection.connect();
connection.login();

I am able to connect, but after 30s I get following “error”:

Aug 18, 2022 9:46:45 AM org.jivesoftware.smack.websocket.okhttp.OkHttpWebSocket disconnect
INFO: WebSocket closing with code: 1000 and message: WebSocket closed normally
Aug 18, 2022 9:46:45 AM org.jivesoftware.smack.AbstractXMPPConnection callConnectionClosedOnErrorListener

Is there something I need to do in order to keep the connection alive? I searched in github and the docs etc. and didn’t really find anything. Or did I get something else wrong?

JFYI: I tried also using stanza (a JavaScript library) and there I can do the following, which actually keeps the connection alive. :wink:

client.enableKeepAlive();

No, would be pretty user unfriendly if an extra step would be required. :wink:

The callConnectionClosedOnErrorListener should be given an exception that caused the connection to disconnect. Knowing this exception would be helpful to determine the cause of the forceful disconnect.

This usually enables whitespace pings or TCP keep-alive packages. I consider both of those mechanismens insuperior to xep199 pings. Have a look at Smack’s PingManager.