【Opcua】 客户端读写时，Opcua Server信息返回处追溯（1）

本文主要是介绍【Opcua】 客户端读写时，Opcua Server信息返回处追溯（1），希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

---

前言

基于前文【Node-RED】node-red-contrib-opcua-server模块使用（2）介绍，我们已经了解到NodeRed现有提供的组件已经无法满足服务端信息的再处理，同时根据前期的研究，Opcua Server提供的库中也不存在信号的回调。因此，目前想到的解决方案，是从修改底层代码出发，只要找到了客户端读写时，Opcua Server的信息返回处，那问题其实就简单了。

在追溯开始前，我们已经在博文【opcua】从编译文件到客户端的收发、断连、节点查询等实现中结束了opcua库的编译产生，因此本博文主要先从生成的编译文件展开分析，如果最终定位在这两个文件，那么只要修改这两个文件就行，其实也不难。

测试文件全放在了资源中，可以直接下载使用。

从客户端角度展开分析

整体思路是，当客户端发起读节点数据操作时候，最终会有一个信息返回，那么我们就根据这个读的函数一一研究就行，以辅以log 输出，代码模块如下：

//sht
UA_LOG_INFO(&client->config.logger, UA_LOGCATEGORY_CLIENT, "sendSymmetricServiceRequest before");
//
...
//sht
UA_LOG_INFO(&client->config.logger, UA_LOGCATEGORY_CLIENT, "sendSymmetricServiceRequest after");
//

初步判断出，函数调用整个流程如下;

• UA_Client_readValueAttribute
• __UA_Client_readAttribute
• UA_Client_Service_read
• __UA_Client_Service
• sendSymmetricServiceRequest
• UA_SecureChannel_sendSymmetricMessage
• UA_MessageContext_finish
• sendSymmetricChunk
• connection->send(channel->connection, &mc->messageBuffer)

到这一步就难受了，因为send函数没有找到，那只能是封装了静态库lib里面了，不死心，以NodeRed 为服务端，qt 中为客户端，跑一下测试一下，整个思路是对的。

从服务端角度展开分析

客户端没有成功，直接从头文件看服务端的函数注释，最终发现UA_Server_read和__UA_Server_read可能存在相关性。通过log辅以查看：

//sht
UA_LOG_INFO(&server->config.logger, UA_LOGCATEGORY_SERVER, "UA_Server_read sht");//

然后以qt搭建opcua 服务器，nodeRed 为客户端，进行测试

只有在连接时候输出了 __UA_Server_read sht ，这意味着这两个方法与读没有关系。同时，根据头文件里面看到的服务端相关的函数，没有与信息返回有关系的，最终同样需要定位到了静态库。

由于静态库由vs编译而来，那得从编译前文件开始查起来，大海捞针，路漫漫。。。继续加油，这过程很有意思！

这篇关于【Opcua】 客户端读写时，Opcua Server信息返回处追溯（1）的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！

---