本文主要是介绍【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）的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
