缘起
将open62541作为中间件使用代替自定义数据的RPC，client通过订阅valueChange来接收数据。使用时发现有一些问题：
- 前后两次产生的数据相同时，不会触发valueChange
- 如果数据更新较快，client会漏掉其中一些数据
探索
问题1：
其实不是问题，这是opcua的属性，valueChange是根据采样（sample）来生成的，并不是server执行了writeValue就会触发事件。只能说这种模式不适合这种每次server产生结果都需要client响应的需求。（有一个小问题，是如何快速判断数值变化的？基本类型可以判断是否和原始数据不相等，对于复杂数据，如图片，逐字节比对？）
问题2：
还是和采样模式相关，如果在两次采样之间数据多次变化是没办法感知的。那就修改采样频率：采样频率同时受server和client的影响，server决定范围，client在范围内决定最终结果。如果client设定为0，则采用server能实现的最快频率。
心生一计
改进方式是将结果通过event发送，设置为report模式。数据内容自己填充，相同的数据也不会被过滤掉；主动report，脱离采样的限制（但响应时间还是受publish间隔的约束）。
event一般是简单消息的通知，承载传递数据的用法不算主流，或许能说明opcua的灵活性吧，不知道这是否存在潜在缺陷。这种模式和pub-sub很类似，不同点在于pub-sub利用的是udp的多播，event还是在server-client的形态下。pub-sub就是为实时性的需求设计的（类似dds），如果只是发送数据，pub-sub会更适合。
使用event基本能满足需求，但是响应的速度还是不够快。网络上查询说是opcua实时性只能到100ms左右，对于目前应用来说，时间上达不到要求。实际测试发现，publish间隔是关键因素，和sample一样，server决定范围，client决定最终结果。将publish间隔设置到1ms，从server发送event到client接收的延迟终于能达标。官方建议不能低于5ms，但测试设置到0也没什么副作用，一开始考虑可能会cpu空转高占用，但并没有。
小插曲
在测试过程中发现在windows平台下，当publish间隔设置为1ms时，本地回环网络还是会有16ms左右的延迟，相同代码在ubuntu下延迟可以稳定在1ms以内。一度为此纠结了很久，一度想换pub-sub甚至dds。后来用asio进行单纯的tcp数据传输测试发现也会有相同的延迟，才确认这是平台的原因（电脑个体差异，待验证？）。Windows下的网络效率不如linux有耳闻，但差距有这么大吗？
补充
在使用qtopcua作为client的过程中，设置相同的参数（publish间隔通过QOpcUaMonitoringParameters设置），还是会有50-60ms的延迟。网上遍寻无果，官方文档不够详细（qtopcua只包含在收费嵌入式的开发套件中，不知道交钱的文档有没有详细些）。最后无奈啃起qtopcua的源码，收获如下：opcua client执行迭代（UA_Client_run_iterate）才会响应event，qt是一个异步的库，qtopcua通过定时器来执行迭代，默认的超时时间就是50ms。通过QOpcUaProvider创建QOpcUaClient时，将超时时间设置放在backendProperties。正确的设置方式如下：
auto client = QOpcUaProvider::createClient("open62541", QVariantMap({"clientIterateIntervalMs", 1}));
server设置sample和publish的间隔范围方式如下：
auto config = UA_Server_getConfig(server); config->publishingIntervalLimits = UA_DurationRange{1.0, 24 * 60 * 60 * 1000}; config->samplingIntervalLimits = UA_DurationRange{1.0, 24 * 60 * 60 * 1000};
client设置publish间隔的方式如下：
auto request = UA_CreateSubscriptionRequest_default(); request.requestedPublishingInterval = 1.0;