Discovery and Session Endpoint URLs|OPC UA Standard|Forum|OPC Foundation

Avatar
Search
Forum Scope


Match



Forum Options



Minimum search word length is 3 characters - maximum search word length is 84 characters
Lost password?
sp_Feed sp_PrintTopic sp_TopicIcon
Discovery and Session Endpoint URLs
Avatar
Sascha Zelzer
Member
Members
Forum Posts: 7
Member Since:
05/05/2015
sp_UserOfflineSmall Offline
1
03/31/2017 - 00:20
sp_Permalink sp_Print sp_EditHistory

I am having difficulties reading the UA 1.03 specifications with respect to endpoint URLs in the context of a server application.

1. url-path handling

The scheme syntax used for “opc.tcp” uses the Common Internet Scheme Syntax and hence seems to allow for an url-path after the port specification. In fact, in Part 4, 7.4 a well known address like “opc.tcp://localhost:4840/UADiscovery” is listed for a discovery endpoint URL.

However, I am not sure how the url-path is to be interpreted (in both discovery and session endpoints). Would a server application be allowed to return a different set of endpoint descriptions in e.g. the GetEndpoints service based on (discovery) endpoint URLs that differ only in their url-path?

Also, would a CreateSession service implementation be allowed to return a service error in case the url-path is not known? If yes, what status code would be appropriate?

2. Multiple discovery URLs

I have a server application (a single process) that listens on endpoints with different host names and port numbers. E.g.

  Server Application            (single process)
    ├ opc.tcp://host1:4841      (server / discovery endpoint)
    │   └ Basic128 Sign         (session endpoint)
    ├ opc.tcp://host1:4842      (server / discovery endpoint)
    │   └ Basic256 Sign&Encrypt (session endpoint)
    └ opc.tcp://localhost:5000  (server / discovery endpoint)
        └ None None             (session endpoint)

 

The session endpoints all access the same underlying system and there is one ServerUri for the whole process (server application).

Is it correct to assume that according to the specifications, the ApplicationDescription returned in the FindServers call (using any of the server endpoint URLs as a discovery URL) may contain three discovery URLs, one for each server endpoint?

A client using the GetEndpoints service with a particular discovery URL would then only get the EndpointDescriptions for the session endpoints associated with the endpoint URL used to access the discovery endpoint, e.g.

 GetEndpoints(“opc.tcp://localhost:5000”)  -> “None None” (session endpoint)

I would highly appreciate any clarifying comments if my reading of the specifications is correct or if there is a more standard-conforming way of organizing such a server structure.

Thanks,

Sascha

Avatar
Randy Armstrong (Sparhawk)
Member
Members
Forum Posts: 20
Member Since:
05/12/2015
sp_UserOfflineSmall Offline
2
04/02/2017 - 06:55
sp_Permalink sp_Print sp_EditHistory

1) The path handling is up to the server. Many UA servers do not care about the path and will simply ignore it. You can develop a server that does make use of it.

2) Multiple DiscoveryUrls exist because not all Clients will support all of the protocols supported by the Server or have access to every NIC used by the Server. The expectation is FindServers/GetEndpoints must return the same information for the same Server no matter what DiscoveryUrl is used. 

Avatar
Sascha Zelzer
Member
Members
Forum Posts: 7
Member Since:
05/05/2015
sp_UserOfflineSmall Offline
3
04/02/2017 - 08:27
sp_Permalink sp_Print

Thanks for 1), that is clear now.

For 2) I would appreciate it if you could comment on the specific example below:

Assume a host machine with two NICs and a server application that listens on e.g. three addresses (made up)

opc.tcp://1.1.1.1:1
opc.tcp://1.1.1.1:2
opc.tcp://2.2.2.2:2

The server sockets are bound to those addresses. If a client connects to one of those addresses, would the following be expected behavior?

a) On a FindServers call, return only one DiscoveryUrl, where the host name in the DiscoveryUrl matches the host name the client used to connect to the server.

b) On a GetEndpoints call using the DiscoveryUrl returned in a), return a list of EndpointDescriptions from all three server endpoints that are accessible to the client (according to Part 4 v1.03, 5.4.4.1). So (assuming the client has no route to access 2.2.2.2)

  GetEndpoints(“opc.tcp://1.1.1.1:1”) -> { “opc.tcp://1.1.1.1:1”, “opc.tcp://1.1.1.1:2”}

but for another client who can access 2.2.2.2 but not 1.1.1.1, it would get

  GetEndpoints(“opc.tcp://2.2.2.2:2”) -> { “opc.tcp://2.2.2.2:2” }

But this is contrary to the expectation you mentioned, that GetEndpoints should return the same list independent of the used DiscoveryUrl.

I am also confused by the possibility of returning multiple DiscoveryUrls in a call to FindServers. Is there a use case for this in the context of a regular server (no gateway, explicit LDS or GDS, etc.)?

Thank you for your help,

Sascha

Avatar
Sascha Zelzer
Member
Members
Forum Posts: 7
Member Since:
05/05/2015
sp_UserOfflineSmall Offline
4
04/02/2017 - 08:58
sp_Permalink sp_Print

After reading through 5.4.4.1 (GetEndpoints service) again, in particular

A Server may have multiple HostNames. For this reason, the Client shall pass the URL it used to connect to the Endpoint to this Service. The implementation of this Service shall use this information to return responses that are accessible to the Client via the provided URL.

I am even more confused. If GetEndpoints is supposed to return the same set of endpoints independent of the DiscoveryUrl being used, how can it possible know what “responses” are accessible to the Client via the provided URL in the GetEndpoints call? Referring to the example in the previous post, who would the server know if it should include the 2.2.2.2:2 endpoint in the response to a client connecting via 1.1.1.1:1?

I think I am missing or misunderstanding something very basic here…

Thanks,

Sascha

Avatar
Randy Armstrong (Sparhawk)
Member
Members
Forum Posts: 20
Member Since:
05/12/2015
sp_UserOfflineSmall Offline
5
04/04/2017 - 14:39
sp_Permalink sp_Print sp_EditHistory

Section 5.4.4.1 does not make sense because the server cant know what the client can and cannot access (even in the case of dual NICs the client could have access to both networks in a redundancy scenario).

I had thought we had removed that text from the spec already. I will see about removing it in 1.04.

Servers should always return all endpoints/discoveryurls (unless filtered by TransportProfileUr in GetEndpoints) because these services are meant to help clients figure out how to connect to a server. If an endpoint is security sensitive then it should not have to be returned to any client and clients would have to be configured out-of-band to connect. 

Avatar
Sascha Zelzer
Member
Members
Forum Posts: 7
Member Since:
05/05/2015
sp_UserOfflineSmall Offline
6
04/12/2017 - 07:55
sp_Permalink sp_Print

Okay, thanks a lot for your help.

It is both Section 5.4.4.1 and the following which got me confused:

Section 5.4.2.2 FindServers and 5.4.4.2 GetEndpoints endpointUrl parameter:

The Server uses this information for diagnostics and to determine what URLs to return in the response.

What does “determine” mean in that context? Does it relate to the host-name, the url-path, or both?

Forum Timezone: America/Phoenix
Most Users Ever Online: 510
Currently Online:
Guest(s) 38
Currently Browsing this Page:
1 Guest(s)
Top Posters:
Forum Stats:
Groups: 2
Forums: 10
Topics: 1444
Posts: 4887