allow fastrouter subscriptions to use hostnames #2012
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Update: Backported in #2013
The following patch allows the following hostname subscriptions:
--subscribe-to NODE_HOSTNAME:3031=ROUTER_HOSTNAME:2626:FASTROUTER_KEY
--subscribe2 addr=NODE_HOSTNAME:3031,server=ROUTER_HOSTNAME:2626,key=FASTROUTER_KEY
instead of manually resolving the IP addresses:
--subscribe-to 10.0.0.2:3031=10.0.0.1:2626:FASTROUTER_KEY
--subscribe2 addr=10.0.0.2:3031,server=10.0.0.1:2626,key=FASTROUTER_KEY
Addresses are resolved by the fastrouter client rather than the server so I didn't have to update the request verification on the server (signing). This also means that new clients can understand hostnames without having to restart the server. If server side address resolution is preferred I can look at updating fastrouter/corerouter, but an initial investigation suggested it was not a simple change.
In addition to above, I also made the following changes:
subscribe-to
parsing by noting thataddr
can actually be specified as long as=
isn't the first character of the "named socket" (and as mentioned above I added hostname resolution on that code path). NOTE: should this be updated in the documentation? Currently the docs suggest you need to usesubscribe2
, but instead of closing the undocumented behavior I updated it to match the handling I was adding tosubscribe2