I am trying to make sense of the Global discovery mechanism observed in OPC UA.
1)Now, specification says, it is useful to find servers in an administrative domain. Just to clarify, here administrative domain means the top level of the automation pyramid? At the office level? Or does it mean that it can be used to find Servers across different networks?
2)I understand, GDS provides facilities for certificate management. Just ignoring the certificate manegement benefits of GDS for now, I would like to know how different of a discovery from multicast subnet discovery would it be?
because, according toGDS Overview, all of it is happening inside a single LAN.
In the same link, does it mean like there are 3 hosts existing? Where Host A has the LDS ME and the server which registers to its local LDS ME. Another host, Host B, has only a LDS ME running on it. So now Host A and Host B communicate via mDNS and each others cache is updated with records. Now GDS which is on Host C, is also on the same LAN. The LDS ME of host B registers to GDS. GDS, then calls for findServersOnNetwork with the LDSME, thus enabling to find details of all the servers.
How will an external client be able to see the records of the GDS? I understand specification says use of a service("Query Servers").
How will it be different from the LDS ME?
We get the same result from multicast subnet discovery as well.
Please let me know. Looking forward for any guidance.
Regards,
Rakshan
Ad 1. The administrative domain can be just about anything. It can be all the things you mentioned, or something else. It depends on the requirements there are for the system.
Ad 2. No, the GDS clients do not have to be on the same LAN.
Ad 3. In most general case, the picture you are referring to has 4 hosts (the 3 you have listed, plus the 4th one for the Client). Your description is otherwise correct except for this part: "Now GDS which is on Host C, is also on the same LAN." The GDS can be on a different LAN. There will be multiple "Host B"-s, one for each LAN that is "served" by the GDS.
Ad 4. An external client connects to a public endpoint of the GDS using normal OPC UA, and calls GDS and CM-related UA methods (not services) described in Part 12 of the UA specification, such as, yes, QueryServers, and more. The main difference from the LDS is that the client can get information about all servers in the administrative domain, not just those that are on its own LAN (or on the LAN it specifically connects to).
Related
Has anyone seen anything on Windows Server 2019 that would prevent browsing the network in a Active Directory domain environment to find available OPC servers on remote hosts when all other OPC communications seem to be functioning normally and file share browsing seems to also be functioning?
There is something I'm missing here, but I cannot find it. Since the core OPC functions are working, tools like OPC Expert are not showing any errors and guides for DCOM settings from OSIsoft, KEPware, and OSI Institute are all being used to no avail. None of the DCOM settings seem to be addressing the CLSID network browsing. If a client has the ability to supply a remote host and query that host, the OPC services enumeration works just fine. The problem is that we are attempting to use clients that do not have any features to manually define the servers and solely relies on the network browsing functions.
Please tell me someone else has seen this behavior. I suspect that it is some network security feature of Windows Server 2019, but I can't find any documentation that points to what might be causing this function to fail. Worse, the function is completing normally, but with zero results, so I don't even have error messages to track the issue down with.
It really depends on the application you are using. There are many ways for an OPC Client to find the remote OPC Server. Most clients will use a combination of the folowing:
OPCEnum. In particular the heavy lifting is done using EnumClassesOfCategories which is part of Component categories Manager. Does not crawl through registry.
GetOPCServers(). This is a method is available as part of an interface called IOPCAutoServer which comes from the OPC foundation itself (via OPCDAAuto.dll)
CLSIDFromProgID() first to get the CLSID and then does the CoCreateInstanceEx().
When CLSIDFromProgID() fails, it falls back to using OPCEnum to list all OPC servers before making a connection.
That means that you would first need to find out what your client application is using to list the OPC Servers.
Then, on the Windows Security side of things, depending on the OS version of both nodes, you may need to disable Simple File Sharing mode (that is the case for Windows XP and older)
If it uses OPCEnum, you will need to configure DCOM for OPCEnum as well, which is the recommended method to list remote OPC Servers.
If the application only supports remote registry lookup to find the OPC Server, then you will need to grant access to the account connecting from the client to the Server
I am working on an embedded software product that runs on an Ubuntu edge computer with multiple network ports.
The software allows the user to change the IP address of the ports via a locally hosted web interface.
In the scenario that a customer changed an IP on one of our devices, but then forgets their setting I am looking for an easy strategy to walk them through detecting the IP.
Ideally this tool would be usable by non-sophisticated customers (we don’t want to walk them through using Wireshark or command line tools).
Is there a service we can setup on our machine that will broadcast its identity across subnets using another protocol like UDP or EtherNet/IP? Then a simple tool the client could install on their computer to ‘scan’ for our devices?
The edge computers also have USB ports if it is easier to broadcast an identify there.
Changing a local IP address to something invalid (=not compatible with its local subnet) generally disables all L3 communication. Limited broadcasts (to 255.255.255.255) still work, but answering to them by unicast most likely won't. The same goes for multicasting - but you could use that for discovery both ways.
Also, the common link-level discovery protocols (like LLDP or CDP) still work since they don't rely on IP.
However, all that is limited to the connected L2 segment at most. Discovery across subnets isn't possible without some kind of infrastructure (discovery sensors, central server, multicast routing, ...). A reasonable way would be dynamic DNS but then again, that requires IP to work.
I think you'd need to take a step back and reevaluate your design. One way would be to verify a user's reconfiguration before it becomes permanent. For instance, you could have a user change the IP setup and then forward the session to the new IP address. If the session isn't continued within five minutes or so on the new address, it reverses to the previous config.
Additionally, some kind of out-of-band management could be useful.
There is a private proxy server IPv4 and 1 port. It is possible to use HTTPS or SOCKS5. It will be used on multiple computers (configuration at the browser level, not a PC). DNS server shared (CloudFlare)
Since I am the owner of this proxy, I want to control and monitor it, namely to see:
the number of devices using it at the moment (online)
workload on proxy, traffic
What sites each computer runs
What of this is possible and with what tools? Is there a general solution (one tool) for all tasks?
Is VPS / VDS required for such purposes? If not, how is an addition than he can be useful?
From present:
Tinyproxy can generate static html file with you needs.
Artica Proxy has a web front end with statistics. Users and transit and sites.
From the past (not maintained):
squid: can generate static html file with your needs.
I have developed Yii2 CRUD application using models, controllers and views. It is used locally on PC. I wanted the users to use it online.
For eg. I have www.example.com and I wanted to make this yii2 CRUD application available on this site. What are the steps?
Your question is not very specific, therefore you haven't received an answer. I'm assuming you are asking about how to use your local PC as the server for an online site. Otherwise please clarify your question.
You will need to do the following steps:
Point the domain name to the public IP address behind which your local PC is sitting. You can find that by going here: http://whatismyipaddress.com/
In your router you need to set up port forwarding (NAT rules) for port 80 (or 443 if using https) to your computer's local IP address.
Depending on your Apache configuration (or whatever webserver you are using) you need to ensure it serves the right website. This is too broad a subject that I can give you any details here.
Note that you are now opening up your local computer to the Internet and hence you should be aware of the security implications it has.
Given these 2 installations:
A machine with 3 OPC UA servers.
A machine with 3 OPC UA servers and a LDS.
What is the difference in functionality? In particular, I would like to know:
Is the installation of a LDS mandatory?
What is the practical difference between discovering a server, then connecting to it, and directly connecting to the endpoint of the server without discovery?
What does installing an LDS enable to do?
(All this, with proper OPC UA specification references where applicable, please)
Is the installation of a LDS mandatory?
No, the installation of an LDS is purely optional. Especially on small / embedded devices you might not even be able to install anything else than the OPC UA server.
What is the practical difference between discovering a server, then connecting to it, and directly connecting to the endpoint of the server without discovery?
With the LDS running on a standarized port (4840) it is possible to discover all servers on the computer without knowing their endpoint URLs. Without an
LDS there is no way to connect to a server without knowing the URL.
As already commented, having the LDS makes discovery (very) slightly slower, as a connection to both LDS and server has to be established.
If only one server is running on the computer one might want to set the port of this server to 4840, so clients discovering on the computer find the server without needing to know a custom port.
What does installing an LDS enable to do?
It simply allows to discover all servers running on the computer without knowing all their different endpoint URLs.
Future versions will contain enhancements, broadcasting this information via Zeroconf, so every LDS would have the list of all OPC UA servers on the local network.