【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编译而来,那得从编译前文件开始查起来,大海捞针,路漫漫。。。继续加油,这过程很有意思!