OPC UA: Local server on port 4840 as LDS and the others as clients #75

kumajaya · 2024-04-10T08:32:55Z

No description provided.

azoitl · 2024-04-10T14:50:40Z

@kumajaya just to be clear: with your change it would still be possible to operate an LDS that would find all 4diac FORTE instances with enabled OPC UA multicast discovery?

kumajaya · 2024-04-10T17:08:13Z

@kumajaya just to be clear: with your change it would still be possible to operate an LDS that would find all 4diac FORTE instances with enabled OPC UA multicast discovery?

Possibly I still don't fully understand the multicast interaction here, please just hold this PR for now.

azoitl · 2024-04-10T18:33:22Z

@kumajaya just to be clear: with your change it would still be possible to operate an LDS that would find all 4diac FORTE instances with enabled OPC UA multicast discovery?

Possibly I still don't fully understand the multicast interaction here, please just hold this PR for now.

Good to know. I set the state of this PR to draft so that we know that it is not ready for merge yet.

kumajaya · 2024-04-11T06:18:39Z

@kumajaya just to be clear: with your change it would still be possible to operate an LDS that would find all 4diac FORTE instances with enabled OPC UA multicast discovery?

Possibly I still don't fully understand the multicast interaction here, please just hold this PR for now.

Good to know. I set the state of this PR to draft so that we know that it is not ready for merge yet.

Initially I just want to make UaExpert to show FORTE's UA server in their server list properly but with this patch, the second FORTE instance (i.e.: with -c localhost:61500 -op 4841 switch) will make the first instance close because both act as LDS server. I have to understand this problem better. I curious how you guys interact with FORTE from IDE with OPC UA profile, haven't been able to get it work even with the latest milestone build.

kumajaya · 2024-04-11T10:54:32Z

@azoitl Sir, now the local server really can act as LDS and another instance can register to it as client, all shown inside UAExpert's ServersOnNetwork list.

azoitl · 2024-04-11T11:27:25Z

@kumajaya I slept this over and I don't think 4diac FORTE should be an LDS. How I understood it was always that the LDS is in charge of managing list of local servers. 4diac FORTE should announce its presence to an LDS. For that we enabled in 4diac FORTE the local multicast announcement. Or did I missunderstand something here?

kumajaya · 2024-04-11T14:06:40Z

@azoitl Sir, I want to understand how OPC UA server interact with LDS. I could be wrong but with the latest change here, now FORTE local server can utilize itself (which run on port 4840) or official OPC UA Local Discovery Server as LDS. I found a bug in the current implementation or I'm just too buggy to understand it 😄

kumajaya · 2024-04-11T14:13:37Z

src/com/opc_ua/opcua_local_handler.cpp

@@ -299,6 +308,7 @@ void COPC_UA_Local_Handler::serverOnNetworkCallback(const UA_ServerOnNetwork *pa
  DEVLOG_DEBUG("[OPC UA LOCAL]: mDNS %s '%.*s' with url '%.*s'\n", paIsServerAnnounce ? "announce" : "remove", paServerOnNetwork->serverName.length,
      paServerOnNetwork->serverName.data, paServerOnNetwork->discoveryUrl.length, paServerOnNetwork->discoveryUrl.data);

+#if 0


After fixing registerWithLds, I found we don't need that function to register to LDS.

kumajaya · 2024-04-11T14:15:39Z

src/com/opc_ua/opcua_local_handler.cpp

  DEVLOG_INFO("[OPC UA LOCAL]: Registering with LDS '%.*s'\n", paDiscoveryUrl->length, paDiscoveryUrl->data);
-  UA_StatusCode retVal = UA_Server_addPeriodicServerRegisterCallback(mUaServer, 0, reinterpret_cast<const char*>(discoveryUrlChar->data), 10 * 60 * 1000, 500, 0);


Without a UA client, this UA_Server_addPeriodicServerRegisterCallback only make FORTE crash.

kumajaya · 2024-04-11T19:11:37Z

Initially I just want to make UaExpert to show FORTE's UA server in their server list properly but with this patch, the second FORTE instance (i.e.: with -c localhost:61500 -op 4841 switch) will make the first instance close because both act as LDS server. I have to understand this problem better. I curious how you guys interact with FORTE from IDE with OPC UA profile, haven't been able to get it work even with the latest milestone build.

@azoitl Sir, I enable OPC UA local server on start and with "opc.tcp://localhost:4840" MGR_ID, now I can interact with FORTE from IDE via OPC UA 😆

azoitl · 2024-04-12T07:03:17Z

Ah you wanted to test the new OPC UA deployment mechanism. This is currently not yet automatically enabled. For testing you need to change the device that is used in main on startup. We are working on a mechanism to select witch device to use from cmake.

kumajaya · 2024-04-12T07:53:17Z

Ah you wanted to test the new OPC UA deployment mechanism. This is currently not yet automatically enabled. For testing you need to change the device that is used in main on startup. We are working on a mechanism to select witch device to use from cmake.

Yes, and you guys are great 👍

I just pushed a change that completely disable unneeded multicast codes with #if 0 .. #endif In my opinion, FORTE doesn't need to be a complete LDS but I don't know the initial multicast design target. With my latest change, all FORTE instance listed inside UAExpert's ServersOnNetwork by utilize LDS from main FORTE instance on port 4840 or OPC UA Local Discovery Server form OPC Foundation

azoitl · 2024-04-12T09:29:16Z

@kumajaya the Multicast part is for enabling the LDS ME extension. I know that this definitely worked once and was needed. Maybe this is a different use case then yours.

kumajaya · 2024-04-15T13:20:58Z

@kumajaya the Multicast part is for enabling the LDS ME extension. I know that this definitely worked once and was needed. Maybe this is a different use case then yours.

I restored the design and now it doesn't crash when a LDS server announces "LDS" message.

cochicde · 2024-05-02T06:23:54Z

Hi,
Thanks for your support!. I worked on the opcua layer some years ago. I had a look at the code again and there's definitely something wrong with the lds multicast. I don't have much experience with this particular part of the opcua, but I took a look at your PR and tried myself locally.

It's definitely not crashing anymore, which is good. I have two questions though:

I tried running the lds server from https://github.com/OPCFoundation/UA-LDS and if I start the lds server after forte, I get the following

error/channel      Connection 10 | SecureChannel 1 | Received an ERR response with StatusCode BadServiceUnsupported and the following reason:

forte is still registered to the lds anyway, so probably this is related to the fact that forte is somehow a lds too. Do you see this error too?
2. I saw a line of code in your PR

if (gOpcuaServerPort == 4840) { //only server on port 4840 announce "LDS" message

why do you need that? is that really the case? I removed the whole block and forte still appears as discovered un uaexpert.

kumajaya · 2024-05-02T13:51:33Z

Hi, Thanks for your support!. I worked on the opcua layer some years ago. I had a look at the code again and there's definitely something wrong with the lds multicast. I don't have much experience with this particular part of the opcua, but I took a look at your PR and tried myself locally.

It's definitely not crashing anymore, which is good. I have two questions though:

I tried running the lds server from https://github.com/OPCFoundation/UA-LDS and if I start the lds server after forte, I get the following
error/channel      Connection 10 | SecureChannel 1 | Received an ERR response with StatusCode BadServiceUnsupported and the following reason: 
forte is still registered to the lds anyway, so probably this is related to the fact that forte is somehow a lds too. Do you see this error too?

Yes, I also got the error. In my understanding, OPC Foundation UA LDS expects the client (forte) make a connection with a security certificate.

I saw a line of code in your PR
if (gOpcuaServerPort == 4840) { //only server on port 4840 announce "LDS" message
why do you need that? is that really the case? I removed the whole block and forte still appears as discovered un uaexpert.

UAExpert ignore LDS on different port but 4840.

cochicde · 2024-05-04T17:48:05Z

Hi, Thanks for your support!. I worked on the opcua layer some years ago. I had a look at the code again and there's definitely something wrong with the lds multicast. I don't have much experience with this particular part of the opcua, but I took a look at your PR and tried myself locally.
It's definitely not crashing anymore, which is good. I have two questions though:

I tried running the lds server from https://github.com/OPCFoundation/UA-LDS and if I start the lds server after forte, I get the following
error/channel      Connection 10 | SecureChannel 1 | Received an ERR response with StatusCode BadServiceUnsupported and the following reason: 
forte is still registered to the lds anyway, so probably this is related to the fact that forte is somehow a lds too. Do you see this error too?
Yes, I also got the error. In my understanding, OPC Foundation UA LDS expects the client (forte) make a connection with a security certificate.
I saw a line of code in your PR
if (gOpcuaServerPort == 4840) { //only server on port 4840 announce "LDS" message
why do you need that? is that really the case? I removed the whole block and forte still appears as discovered un uaexpert.
UAExpert ignore LDS on different port but 4840.

I think the whole block is not needed. As Alois mentioned, I think forte shouldn't be a LDS server, or at least that was not the intention initially.

How it works, is that you have one LDS server (or more, but let's stay with one for simplicity) and any opc ua server, forte in this case, would then register itself to this LDS server. When you use UaExpert later, you basically then ask the LDS server for the list of regular servers which were registered and you get the list. One problem is that you have to know the LDS server endpoint to register yourself.

That's where multicast come into play. The LDS-ME server sends a multicast message announcing itself, which in this case forte receives it (and doesn't crash anymore, thanks again), takes the discovery endpoint from the message and then it regsiter itself and the process is the same.

More info here

So, knowing this, I would say forte is not suppose to be a LDS. It could be, yes, but in general doesn't go well with a normal architecture.

One important thing: UaExpert doesn't show the LDS servers (https://forum.unified-automation.com/topic1987.html)

So, basically I removed the block about "LDS" capability and i could see forte in uaExpert when the discovery server is runnning.
One more bad thing with the current code, which you could adapt here to have it working properly:

line 167: paUaServerConfig.applicationDescription.applicationType = UA_APPLICATIONTYPE_DISCOVERYSERVER -> this is not needed, it's actually wrong. This makes forte a LDS server and it doesn't show in UaExpert properly. You can remove this line

I would recommend to remove this line and the whole code block if (gOpcuaServerPort == 4840) { and try it again. I can see my forte there. The URL you see below, is actually the LDS server which is running in parallel, not forte.

kumajaya · 2024-05-05T03:40:01Z

@cochicde Thank you for your review and explanations. I will recheck this later.

azoitl marked this pull request as draft April 10, 2024 18:32

kumajaya force-pushed the fix/opcua-1 branch from f05a53b to 045bd1a Compare April 11, 2024 10:47

kumajaya changed the title ~~OPC UA: Local server as LDS and UA service~~ OPC UA: Local server as local discovery server or client Apr 11, 2024

kumajaya force-pushed the fix/opcua-1 branch from 045bd1a to 0313eb5 Compare April 11, 2024 13:51

kumajaya commented Apr 11, 2024

View reviewed changes

kumajaya force-pushed the fix/opcua-1 branch from 0313eb5 to 54c39ce Compare April 11, 2024 17:18

kumajaya force-pushed the fix/opcua-1 branch from 54c39ce to a8967bc Compare April 12, 2024 07:39

OPC UA: Local server on port 4840 as LDS and the others as clients

ae14d24

kumajaya force-pushed the fix/opcua-1 branch from a8967bc to ae14d24 Compare April 15, 2024 13:16

kumajaya changed the title ~~OPC UA: Local server as local discovery server or client~~ OPC UA: Local server on port 4840 as LDS and the others as clients Apr 15, 2024

kumajaya mentioned this pull request Apr 15, 2024

OPC UA local server multicast support is broken #82

Open

cochicde mentioned this pull request Sep 22, 2024

fix and move ldsMe to its own class #239

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

OPC UA: Local server on port 4840 as LDS and the others as clients #75

OPC UA: Local server on port 4840 as LDS and the others as clients #75

kumajaya commented Apr 10, 2024

azoitl commented Apr 10, 2024

kumajaya commented Apr 10, 2024

azoitl commented Apr 10, 2024

kumajaya commented Apr 11, 2024

kumajaya commented Apr 11, 2024

azoitl commented Apr 11, 2024

kumajaya commented Apr 11, 2024

kumajaya Apr 11, 2024

kumajaya Apr 11, 2024

kumajaya commented Apr 11, 2024

azoitl commented Apr 12, 2024

kumajaya commented Apr 12, 2024

azoitl commented Apr 12, 2024

kumajaya commented Apr 15, 2024

cochicde commented May 2, 2024

kumajaya commented May 2, 2024

cochicde commented May 4, 2024

kumajaya commented May 5, 2024

		DEVLOG_INFO("[OPC UA LOCAL]: Registering with LDS '%.*s'\n", paDiscoveryUrl->length, paDiscoveryUrl->data);
		UA_StatusCode retVal = UA_Server_addPeriodicServerRegisterCallback(mUaServer, 0, reinterpret_cast<const char>(discoveryUrlChar->data), 10 60 * 1000, 500, 0);

OPC UA: Local server on port 4840 as LDS and the others as clients #75

Are you sure you want to change the base?

OPC UA: Local server on port 4840 as LDS and the others as clients #75

Conversation

kumajaya commented Apr 10, 2024

azoitl commented Apr 10, 2024

kumajaya commented Apr 10, 2024

azoitl commented Apr 10, 2024

kumajaya commented Apr 11, 2024

kumajaya commented Apr 11, 2024

azoitl commented Apr 11, 2024

kumajaya commented Apr 11, 2024

kumajaya Apr 11, 2024

Choose a reason for hiding this comment

kumajaya Apr 11, 2024

Choose a reason for hiding this comment

kumajaya commented Apr 11, 2024

azoitl commented Apr 12, 2024

kumajaya commented Apr 12, 2024

azoitl commented Apr 12, 2024

kumajaya commented Apr 15, 2024

cochicde commented May 2, 2024

kumajaya commented May 2, 2024

cochicde commented May 4, 2024

kumajaya commented May 5, 2024