Resolution:
Initially, the remote client implementation was done such that it can only connect to the remote listening port and not to the “regular” listening port. This restriction has been removed and remote clients can connect through either of the two. The remote listen needs to be used in an environment where the traffic among the Seeders and the traffic between the clients and proxies need to be segregated. There can be a faster and more reliable backbone interconnecting the peer members whereas the client traffic can be routed through a “public” network as shown in the attached diagram (Filename: remote_client.jpg).

If the clients and the proxies are “near” to each other (same subnet), the remote_listen is not needed. This was introduced along with the multi proxy implementation in 2.1.5. The only restriction is that the client should not specify a discovery URL that has the remote_listen and the listen pointing to the same cluster member.

Example: Two as-agents started as follows:

    as-agent –listen tcp://127.0.0.1:50000 –remote_listen tcp://127.0.0.1:60000
    as-agent –listen tcp://127.0.0.1:50001 –remote_listen tcp://127.0.0.1:60001


The following command is valid for the client:

    ASOperations –discovery tcp://127.0.0.1:50000;127.0.0.1:60001?remote=true

The following should not be done. Though there is no check to detect the condition, this would result in the member being left in an indeterminate state:

    ASOperations –discovery tcp://127.0.0.1:50000;127.0.0.1:50001?remote=true ==> Both the ports here are from the 1st agent.