View Issue Details

IDProjectCategoryView StatusLast Update
000467710000-012: DiscoveryApi Changepublic2022-05-10 16:48
ReporterJouni Aro Assigned ToRandy Armstrong  
PrioritynormalSeverityminorReproducibilityhave not tried
Status closedResolutionfixed 
Fixed in Version1.05.02 RC1 
Summary0004677: Format of Client EndpointUrl for reverse connections
Description

The specification (1.04, Part 6. 7.1.3) defines:

"The Server needs to be configured and enabled by an administrator to connect to one or more
Clients. For each Client, the administrator shall provide an ApplicationUri and an EndpointUrl
for the Client. If the Client EndpointUrl is not known, the administrator may provide the
EndpointUrl for a GDS (see Part 12) which knows about the Client."

The text mixes different EndpointUrls, so it is a bit hard to follow, which is which, but it also talks about 'the Client EndpointUrl' giving an impression that the reverse socket that the client opens, should be referred with a similar EndpointUrl as the server's EndpointUrl, i.e. 'opc.tcp://clienthost:clientport'. I am not sure if it is a good idea to use a similar URL - or if this even is the intention. Anyway, it would be good to clarify this.

If the administrator is to configure the EndpointUrl of a GDS, then he also needs to configure the ApplicationUri of the client - or how is the server supposed to find the client from the GDS? And even worse: how can the GDS provide the reverse endpoint of the client? Part 12 does not talk about EndpointUrls for clients...

TagsNo tags attached.
Commit Version
Fix Due Date

Activities

Jouni Aro

2019-03-15 08:15

reporter   ~0010055

Last edited: 2019-03-15 08:16

Hmm. After a few more readings, I get it that "For each Client, the administrator shall provide an ApplicationUri and an EndpointUrl
for the Client" talks about the parameters OF the client, not OF the server for the client, which are the parameters that are sent in the ReverseHello message.

So, yes, there is an ApplicationUri that could be used to fetch the EndpointUrl of the client - and Part 12 actually mentions that the EndpointUrl should be prepended with 'inv+', if it is defined for the client. But would be good to clarify if this is the format that is expected to be used in server configuration or if it is left totally open. After all, the server needs to configure the hostname and port only, so the format is free in that sense.

('inv+' sounds a bit odd; mainly we are mixing terms 'inverse' and 'reverse' here, which I don't like very much. In that sense, 'rev+' would have been better, but apparently, I am late, once again.)

Randy Armstrong

2022-03-03 08:55

administrator   ~0016144

Text in Part 12 now clarifies what needs to happen:

1) Applications that support Reverse Connect have an ApplicationType of "Client" or ClientAndServer";
2) Applications that support Reverse Connect shall specify the RCP server capability;
3) Any DiscoveryUrls which support Reverse Connect have the prefix 'rcp+';

Configuration applications/servers looking for endpoints can pass the ApplicationUri into the QueryApplications on a GDS to get the DiscoveryUrls.

Jim Luth

2022-05-10 16:48

administrator   ~0016699

Agreed to changes edited in telecon.

Issue History

Date Modified Username Field Change
2019-03-13 11:19 Jouni Aro New Issue
2019-03-15 08:15 Jouni Aro Note Added: 0010055
2019-03-15 08:16 Jouni Aro Note Edited: 0010055
2021-04-14 17:35 Jim Luth Project UA => 10000-006: Mappings
2021-08-19 05:06 Randy Armstrong Project 10000-006: Mappings => 10000-012: Discovery
2021-11-30 17:48 Jim Luth Assigned To => Randy Armstrong
2021-11-30 17:48 Jim Luth Status new => assigned
2022-03-03 08:55 Randy Armstrong Status assigned => resolved
2022-03-03 08:55 Randy Armstrong Resolution open => fixed
2022-03-03 08:55 Randy Armstrong Note Added: 0016144
2022-05-10 16:48 Jim Luth Status resolved => closed
2022-05-10 16:48 Jim Luth Fixed in Version => 1.05.02 RC1
2022-05-10 16:48 Jim Luth Note Added: 0016699