OPC UA 发现中的多播 DNS 名称冲突

Posted 2023-02-19

【中文标题】OPC UA 发现中的多播 DNS 名称冲突

【英文标题】：Multicast DNS name conflict in OPC UA Discovery

【发布时间】：2021-04-22 13:48:53

【问题描述】：

处理向客户端显示服务器状态信息（可用或忙碌）的需求。 遵循2种方法：

使用服务器功能阵列工具来显示信息。因为它是一个数组，所以第一个元素是服务器的特征，第二个元素是状态（初始可用）。服务器配置（多播服务器的最大会话更改为 1。发生这种情况时，功能数组的第二个元素更改为忙碌。但是，在运行客户端应用程序时（来自 open62541 发现示例的 findServersOnNetwork.c），这是未反映，因为配置参数的值是在服务器运行之前获取的（例如：始终可用状态）

2) 使用相同的服务器能力数组扩展，这一次，一旦建立会话，我取消注册服务器，将能力列表更改为忙碌并再次注册服务器。 但是在这样做的时候，我得到一个错误： 检测到多播 DNS 名称冲突：“Crane Multicast Server-._opcua-tcp._tcp.local。”对于 16 型

我已附上成功注销（删除记录）的LDS日志。然而它显示了冲突。 请让我知道这里可能是什么问题？ 尽管删除了记录，但冲突是不能接受的，对吧？

Image of the LDS Log

复制步骤： server_multicast.c（来自 open62541 堆栈的示例部分）

while(running== true)
            UA_Server_run_iterate(server, true);
               if(count!=1)
                    if(time(0)>timestamp)
                       timestamp= time(0) + 3;
                       int count= getCountValue(); //returns the count of sessions currently
                       printf("Num: %d\n",count);
                       caps[0]= UA_String_fromChars("Available");
                       if(count==1)
                           //caps[1]= UA_String_fromChars("Busy");
                           //printf("The server status is: %.*s\n", caps[1]);
                           if(check==false)
                             returnValue =Routine_run(server,clientRegister,config,endpointUrl,caps); // to dereg, change caps and register again
                                   printf("The server status is: %.*s\n", returnValue);
                                   check=true;
                           else
                               continue;
                           
                        
                       else
                           continue;
                       
                    
               
             else
                 continue;
             

    

static UA_String Routine_run(UA_Server *server, UA_Client *clientRegister,UA_ServerConfig *config,char *endpointUrl,UA_String *caps)
    UA_StatusCode retval;
    retval = UA_Server_unregister_discovery(server, clientRegister);
    if(retval != UA_STATUSCODE_GOOD)
        UA_LOG_ERROR(UA_Log_Stdout, UA_LOGCATEGORY_SERVER,
                     "Could not unregister server from discovery server. "
                     "StatusCode %s", UA_StatusCode_name(retval));
    else
            UA_LOG_ERROR(UA_Log_Stdout, UA_LOGCATEGORY_SERVER,
            "Unregistration Successfull. "
            "StatusCode %s", UA_StatusCode_name(retval));
    
     UA_Server_removeCallback(server, callbackId);

    caps[1] = UA_String_fromChars("Busy");
    UA_StatusCode retval2= UA_Server_register_discovery(server, clientRegister, NULL);
    if(retval2 != UA_STATUSCODE_GOOD)
            UA_LOG_ERROR(UA_Log_Stdout, UA_LOGCATEGORY_SERVER,
                         "Could not register server from discovery server. "
                         "StatusCode %s", UA_StatusCode_name(retval));
            caps[1] = UA_String_fromChars("FAIL");
        else
                UA_LOG_ERROR(UA_Log_Stdout, UA_LOGCATEGORY_SERVER,
                "registration Successfull. "
                "StatusCode %s", UA_StatusCode_name(retval));
                caps[1] = UA_String_fromChars("Busy");
        
   return caps[1];

【问题讨论】：

你应该用“服务器的状态信息（可用或忙碌）”来定义你的意思。但是在通常对服务器状态（=客户端是否可以成功连接和使用它）的理解中，它的状态根本不能从它在UA Discovery或（m）DNS中的注册得到。这些东西几乎与服务器状态无关。

是的，可用和忙碌的意思是说服务器是否空闲或正在与另一个客户端进行会话。 OPC UA 定义了一种发现机制，其中服务器能够在服务器能力标识符中提供其特征。我正在使用此功能扩展发现机制以显示状态信息（即可用或忙碌）。我已将服务器配置为只有 1 个会话，然后根据会话数，我将状态信息从“可用”修改为“忙碌”。 “可用”是因为当我运行服务器时，最初它是免费的

我已经做了一些方法。一种是直接与会话计数进行比较，当会话计数为 1 时，功能列表更改为忙。然而，这并没有反映在客户端的角度，因为客户端在服务器运行之前获取状态信息。所以在另一种方法中，我做了我在这篇文章中提到的。每当我看到会话计数为 1 时，我都会取消注册服务器，更改功能并再次注册......（希望在功能列表上看到更新）。

但这似乎没有发生，因为未注册的服务器记录并没有被堆栈代码完全从网络中删除，并且再次注册会产生名称冲突..您有什么建议吗？ @ZbynekZ

【参考方案1】：

关于“可用和忙，我们的意思是说服务器是空闲还是正在与另一个客户端进行会话。OPC UA 定义了一种发现机制，服务器能够提供其功能......”：

即使在技术上可行，您也无法通过 OPC UA 发现提供此信息而不违反 OPC UA 发现规范。

【讨论】：

哦好的..我无法理解这里的违规部分..你能提供一些见解吗？我的意思是，是因为功能只显示服务器的功能而不应该是其他任何东西吗？我们可以周而复始地进行扩展吗？

功能列表由 OPC 基金会控制。您不能添加自己的。此外，服务器应根据发现的存在而不是状态向发现注册/取消注册。它目前无法接受连接这一事实并不是它注销自身或以不同方式注册的理由。