The discovery process for reverse connect does not serve the same purpose as the discovery process for normal connections because reverse connections require the Server to be configured to automatically attempt to connect to the Client and the Client to be configured so it knows what to do with the Server when it receives the connection. The limited mechanisms discussed here may help SecurityAdmins with the configuration of Servers.

A SecurityAdmin tasked with configuring Servers needs to determine the ClientUrls for Clients that support reverse connect.

The following choices are available:

The mechanisms based on an LDS are not available since Clients do not register with the LDS.

Every Client that supports reverse connect has one or more ClientUrls that allow Servers to connect. Once the SecurityAdmin acquires the ClientUrl via an out-of-band mechanism, it can configure the Server to use it.

A GDS is a Server which allows other SecurityAdmins to search for Clients that support reverse connnect within the administrative domain of the GDS. The SecurityAdmin uses the Call service to invoke the QueryApplications Method (see 6.6.11) with “RCP” as a serverCapabilityFilter to get a list of Clients that support reverse connect from the GDS.

The discovery process is illustrated in Figure 5.


Figure 7 – The Global Discovery Process for Reverse Connections

The ClientUrls are returned in the DiscoveryUrls parameter of the ApplicationDescription record and have the ‘rcp+’ prefix. DiscoveryUrls without the prefix are used for forward connections. Once the SecurityAdmin has a ClientUrl it can configure the Server to use it.