我针对KEPServerEX版本5.2使用Eclipse Milo Client SDK 0.2.2,有时会失去连接。 在我的日志中,我得到了这些堆栈跟踪:
ERROR 5048 --- [hared-pool-1693] o.e.m.o.s.c.h.UaTcpClientMessageHandler : Error decoding asymmetric message: expected sequence number 1140680 but received 1140681
org.eclipse.milo.opcua.stack.core.UaException: expected sequence number 1140680 but received 1140681
at org.eclipse.milo.opcua.stack.core.channel.ChunkDecoder$AbstractDecoder.decode(ChunkDecoder.java:166)
at org.eclipse.milo.opcua.stack.core.channel.ChunkDecoder.decode(ChunkDecoder.java:83)
at org.eclipse.milo.opcua.stack.core.channel.ChunkDecoder.decodeAsymmetric(ChunkDecoder.java:63)
at org.eclipse.milo.opcua.stack.client.handlers.UaTcpClientMessageHandler.lambda$onOpenSecureChannel$6(UaTcpClientMessageHandler.java:492)
at org.eclipse.milo.opcua.stack.core.channel.SerializationQueue.lambda$decode$1(SerializationQueue.java:64)
at org.eclipse.milo.opcua.stack.core.util.ExecutionQueue$PollAndExecute.run(ExecutionQueue.java:107)
ERROR 5048 --- [hared-pool-1677] o.e.m.o.s.c.h.UaTcpClientMessageHandler : Error validating chunk headers: received unknown secure channel token: tokenId=57 currentTokenId=56 previousTokenId=55
org.eclipse.milo.opcua.stack.core.UaException: received unknown secure channel token: tokenId=57 currentTokenId=56 previousTokenId=55
at org.eclipse.milo.opcua.stack.client.handlers.UaTcpClientMessageHandler.validateChunkHeaders(UaTcpClientMessageHandler.java:704)
at org.eclipse.milo.opcua.stack.client.handlers.UaTcpClientMessageHandler.lambda$onSecureMessage$10(UaTcpClientMessageHandler.java:621)
at org.eclipse.milo.opcua.stack.core.channel.SerializationQueue.lambda$decode$1(SerializationQueue.java:64)
at org.eclipse.milo.opcua.stack.core.util.ExecutionQueue$PollAndExecute.run(ExecutionQueue.java:107)
我的代码中有一个线程,该线程通过每5分钟轮询服务器上的特定标签来使会话永久打开。 在令牌错误发生后恰好一个小时发生读取超时。我怀疑在发生令牌错误后,我不允许更新/延长会话长度。 之后,我再也无法使用该会话了。
这是来自OPC服务器的预期行为,应该处理吗?
我知道我可以在keep-session-open-thread中处理超时,也许断开连接并创建一个新的会话,但是有没有更优雅的方法呢?
答案 0 :(得分:0)
这里不需要做任何事情(在代码中)。
您可能需要将KEPServerEX升级到最新版本。还提供了较新版本的Milo(0.2.4),但我认为没有发现或解决过类似的问题。
似乎发生了什么:
1)KSE虚假地发送了一个用未来的令牌保护的大块。
2)KSE收到安全的频道更新请求,并且在发送响应之前,它使用新令牌来保护块。 (这很可能是原因,而且听起来似乎有点熟悉)