Yes, it’s a double-edged sword. From a developer’s view, it’s great that this behavior reveals an issue, so that it can be fixed.
But imagine a large customer base in a closed system which have a buggy client and suddenly all clients start to disconnect after a server upgrade. You will get a lot of support requests from angry customers, you have to analyze the issue and eventually you will downgrade the server again to make the customers happy again.
Updating the clients is even more complicated considering a full software release cycle.
The point is that you don’t need to update the client, just disable Stream Management on client side.
The app i am working on is almost unusable in its current state because of these disconnects.
Somehow I saw that coming.
See also this discussion:
https://mail.jabber.org/pipermail/standards/2018-February/034231.html
I guess the latest Openfire now terminates the stream.
Gracefully ignoring too high h values might have been the better alternative.
I think the situation now is far better, otherwise we wouldn’t became aware that something is off. As client library developer I’m deeply thankful that the issue was pointed out, which very likely wouldn’t be case if the server would simply ignore inconsistent response.
Also the user can simply turn off stream management to avoid the issue. Turning off stream management in such a case doesn’t mean much service degradation, because the stream management implementation is probably unreliable anyway.
Isn’t it the same actually? Disabling SM requires that there’s a configuration option, e.g. a UI checkbox, which the end user could use. But since most end users “just expect it to work” and don’t care about protocol features like SM, there’s usually no such config option.
Maybe a client has something like a configuration file, but you would need to deploy it to every client, which isn’t easy if you have to stick to release cycles or have no control over client installations.
Imagine thousands of customers, “DAUs”, which can’t be told “please disable stream management”, even if there are config options.
The only short-term solution would be to disable stream management on server-side.
But as it seems, it’s an Openfire issue anyway.
I wonder if problems with constantly disconnecting clients like Swift, Jitsi and Pidgin in the past are related to this. Swift gives Stream Error when it disconnects and reconnects (Openfire 4.2.2). Not sure when exactly it started, maybe with 4.0 branch.
I think the “terminating the stream” behavior was only added recently in Openfire, I think in 4.2.