OpenFire and IEC 61850-8-2

Openfire Openfire Support
1

For test purposes, we are currently testing an application that connect 10 000 x IEC 61850-8-2 Clients/Servers (all acting as XMPP clients) to OpenFire XMPP Server.

At this moment, we successfully connected 50 x 61850-8-2 Servers to communicate with 50 x IEC61850-8-2 Clients. However, we could make it work after adding a 1 minute delay between XMPP connection and the initiate request from client. Also, when adding more servers , open fire closes the connection randomly. The log says something about an internal failure while processing a xml, resulting a connection loss at the client side.

It seems that OpenFire gives total priority to roster and other XMPP internal messages rather than the ones from IQ type used by the protocol.

Is there anything that we could do to tune XMPP Server in order to solve this issue ?

2

Hi Julien. It’s interesting to see more standards making use of XMPP. I’m not familiar with IEC 61850-8-2, and when quickly googling for it, I hit seem to hit some kind of paywall.

Having one Openfire (server) serve 50 clients concurrently should not have any kind of issue. If you run into issues with these low numbers, then some kind of bug or severe inefficiency in client code or server-sided customisation is very likely.

Having one Openfire serve 10,000 clients concurrently generally is not a problem either. However, here behavior can become a factor. Having them authenticate/log in all at the same time, for example, might introduce some bottlenecks.

In the above, I’m talking about using one server. You seem to indicate that you’re using more than one Openfire. That generally distributes load, so things should not be worse - but again, this depends on the specifics on how you make those servers interconnect.

3

Thanks your reply @guus ! I need to explain about IEC 61850. It’s a communication protocol used in Power Industry. It’s a Client/Server protocol. In the variant IEC 61850-8-2, transport layer is XMPP. It means that IEC 61850 Servers and IEC 61850 Clients are connected to a XMPP Server. An IEC 61850 Client can receive data from multiple IEC 61850 Servers. Each client has one JID and each server has one JID.

We are currently investigating our issues :

  • It seems that the XMPP Server can´t handle several messages with request-responses.

1 - With 5 Servers configured in a Client, just the fact of sending 5 init-request messages to all at the same time (one for each) is enough for the XMPP Server to disconnect.

We can see message like this in our log :
20/04/2021 00:58:25.027 (43C0) DRIVER	Disconnected: The stream has been closed (by the server)

So, We think it is much more stable when messages are arriving from multiple clients, it seems there is a limit of pending messages from a single account.

It seems that when an account sends several messages at the same time, the XMPP Server crashes. But if several messages are arriving into one account from different accounts (61850 servers) it works well.

Perhaps if we could first enable a better logging function (with timestamps) on Openfire, we coud investigate more. Is there any way to get bigger log files with timestamps ?

Secondly, we need to discover how to improve the application and if someone could fix the code or check if we can raise this message limit.

We tried to disable Stream Management as it was suggested in a similar issue but it didn’t work. If the client starts making polling requests frequently the XMPP Server crashes.

2021.04.20 04:34:37 org.jivesoftware.openfire.nio.ConnectionHandler - Closing connection due to error while processing message: <iq to='gateway95@xmpp1.tprider.com.tw/IEC' id='5be9f5803fbc237bcb4f1222344936cb1739faeb0000fa63' type='get' xmlns='jabber:client'><ping xmlns='urn:xmpp:ping'/></iq>

This is the error message :

2021.04.20 04:44:37 WARN [socket_c2s-thread-16]: org.jivesoftware.openfire.nio.ConnectionHandler - Closing connection due to exception in session: (0x0000018F: nio socket, server, null => 0.0.0.0/0.0.0.0:5222)
java.io.IOException: Connection reset by peer

After disabling the stream management it seems the driver stopped working.

4

From the above, my guess is that the client does not adhere to the XMPP specification properly, particularly when sending data. From what you’re writing, I wonder if something around how you address XMPP streams and stanzas is off. It’s hard to tell exactly what’s going on without performing more of an in-depth analysis. Maybe you should consider acquiring some support from one of the service providers so that you can have someone that digs into your specific solution, and help you further.

The XML Debugger plugin can help you log all traffic that Openfire sends and receives. That might be useful for debugging purposes.

My advise to you would be to stop worrying about optimizing things (like with applying Stream Management). There appears to be a functional problem somewhere. That needs to be resolved first. Adding other things to the solution will only muddy the water, by making things more complex, without resolving the root causes of your issue.

5

Hi Guus. Sorry for the long delay for this feedback. We finally solved our problem, your answer helped us to think about the causes of our issue.