Regarding LDS - ME

Unified Architecture topics related to OPC UA Specification, compliant behavior and any technical issues of OPC UA, like Security, Information Model, Companion Specs DI, PLCopen, ADI, ...

Moderator: Support Team

Post Reply
rakshan
Full Member
Full Member
Posts: 9
Joined: 07 Jun 2019, 08:35

Regarding LDS - ME

Post by rakshan »

Hello,
I have a query regarding the Discovery mechanism.
From what I understand, servers running on the same host as of LDS, can register themselves to the LDS, which would help the clients to figure out the list of servers running.The discovery URL could be constructed using opc.tcp://hostname;port/UADiscovery.

But when moving to the LDS ME, as specified as MulticastSubnet DIscovery in OPC UA part 12, from what I see, the client machine also has a LDS ME installed on it to probe the LDS ME of the server.
Server which needs to be registered only makes itself discoverable through LDS right? How is the client having the LDS-ME as well?
Is it that with every OPC UA application(here client) running on a host, that particular host should have a LDS ME?

Question could be really Silly and dumb. But I cannot think of a better way to put it forward. Please let me know.


Regards,
Rakshan

User avatar
Support Team
Hero Member
Hero Member
Posts: 3064
Joined: 18 Mar 2011, 15:09

Re: Regarding LDS - ME

Post by Support Team »

Hello,

you are writing that
The discovery URL could be constructed using opc.tcp://hostname;port/UADiscovery.
Where did you get this information from? no semicolon allowed, no UADiscovery required. You better read the UA specification instead.

The LDS ME has additional functionality and can obtain list of server URIs from "other" LDS ME. With that, the LDS ME can obtain the list "all" servers within a subnet all announcing their lists vice versa. On a particular PC you have either the LDS or the LDS ME installed. For the server is same procedure (must register at LDS/LDSME). For client is also same either call "FindServers()" to local LDS (or LDS ME) and get return the list of local registered server, OR call FindServerOnNetwork() to the local LDS (or LDS ME) and get a list of server URIs of "all" servers in the subnet (if only poor LDS (non ME) is installed would reject the call FindServersOnNetwork). Clever clients would probably call FindOnNetwork first and fall back to FindLocal is call gets rejected, hence could deal with both LDS variants (automatically). BTW that would be required if you hit a server running directly on 4840 (no LDS at all), because that server would respond to FindServers() only.

Your client can either bring its own LDS ME, or the LDS ME is already installed (by someone else) and can just be used. It's a shared component in terms of installation (that is why OPCF provides as MSM merge module, for easy integration into application setups). However, what if on this box already a "normal" LDS exist, must uninstrall first. Also possible that your client just "knows" one PC where an LDS ME is installed and just calls this one remotely with FindServersOnNetwork(). Or you clients pops up a GUI and ask the user to type in an IP addres to probe (which is more or less what the UaExpert is doing)
Best regards
Unified Automation Support Team

rakshan
Full Member
Full Member
Posts: 9
Joined: 07 Jun 2019, 08:35

Re: Regarding LDS - ME

Post by rakshan »

Hello,
Thanks for your answer.
Semicolon was a typo from my side.. And the URL was found in WellKnownAddresses Part 6 of the Specifications.(Section 7.6)

However, i have another question. regarding the multicast probing and announcements as specified in MulticastSubnet discoverry in specification 12.
In such scenario, after server registers to its LDS of server, and when client gets plugged in, the LDS in the client, sends a probe message on which LDS of the server responds with an announcement.

I am very curious to know, what exactly is the multicast probe and announcement message here.

(In my research for basics of mDNS I understood that, probe is nothing but a query where in a network of 4 client nodes, if client1 needs client4 ip, client1 will send a multicast query to all the nodes with "client4.local", and then there is response from client4)

How exactly is it happening in this case with the client and server? Does the client LDS-ME, send a multicast message by constructing the hostname by out of band mechanism eg: hostname.local and get server information? But this would not really make sense as the Multicast subnet discovery is for the clients who have no idea about the hosts...

Please let me know.



Regards,

Rakshan

Post Reply