0

Working on a requirement to display the status information of the server( Available or Busy) to the client. 2 approach followed:

  1. used the facility of server capabilities array to display information. As it is an array, 1st element was made to be the feature of the server and 2nd element, to be the status(Initially- Available). The server config(of the multicast server is changed to max session of 1. When this happens the 2nd element of the capability array is changed as Busy. However, while running the client application(findServersOnNetwork.c from open62541 discovery examples), this is not reflected, as values of the config parameters are taken before the server runs( eg: Available status throughout)

2)Using the same server capabiltity array extension, this time, once a session is established, I unregister the server, change the capability list to Busy and register the server again. But while doing so, i get an error : Multicast DNS name conflict detected: 'Crane Multicast Server-._opcua-tcp._tcp.local.' for type 16

I have attached the log of the LDS of successful deregistration( removal of the record). Yet it shows a conflict. Please let me know what could be the issue here? Inspite of the removal of records, the conflict is not acceptable right?

Image of the LDS Log

Reproduction steps: server_multicast.c( from the example section of open62541 stack)

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];

}
  • You should define what you mean by " the status information of the server( Available or Busy)". But in the usual understanding of server status (= whether client can successfully connect and work with it), its status cannot be derived from its registration in UA Discovery or (m)DNS at all. These things are almost unrelated to the server status. – ZbynekZ Jan 19 '21 at 08:50
  • yes, By available and busy, we mean to say whether server is free or is having a session with another client. OPC UA defines a discovery mechanism where the server is capable of providing its feratures in the server capability identifier. I am using this feature to have an extension to discovery mechanism to display the status information(ie Available or Busy) . I have configured the server to have only 1 session and then based on the count of sessions, I am modifying the status information from "Available" to "Busy". "Available " is coz when i run the server, initially it will be free – Rakshan Premsagar Kapikad Jan 20 '21 at 08:18
  • I have done a couple of approaches already. One was sort of a direct comparison with the count of sessions and when the session count was 1, the capability list was changed to busy. However, this does not reflected on the client perspective because the client takes the status information before the run of the server. So in another approach, I do what I mentioned in this post. Whenever I see the session count as 1, I deregister the server, change the capability and register it again..(hoping to see the update on the capability list). – Rakshan Premsagar Kapikad Jan 20 '21 at 08:19
  • But this does not seem to happen, as the unregistered server records are not removed completely from the network by the stack code, and registering again gives a name conflict..Anything you could suggest? @ZbynekZ – Rakshan Premsagar Kapikad Jan 20 '21 at 08:22

1 Answers1

0

Re "By available and busy, we mean to say whether server is free or is having a session with another client. OPC UA defines a discovery mechanism where the server is capable of providing its feratures ..." :

Even if it was possible technically, you can not provide this information through OPC UA discovery without violating the OPC UA discovery specification.

ZbynekZ
  • 1,532
  • 10
  • 16
  • Oh ok.. I am not able to understand the violation part here.. Could you give some insights? I mean, is it because capabilities show only the features of the server and should not be anything else? We can tweek around and make the extension right? – Rakshan Premsagar Kapikad Jan 20 '21 at 09:06
  • The list of capabilities is controlled by the OPC Foundation. You cannot add your own ones. In addition, the server should register/unregister with the discovery based on its existence, and not on its status. The fact that it cannot currently accept a connection is no reason for it to deregister itself, or register differently. – ZbynekZ Jan 20 '21 at 12:31