New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

API connections fails when used from remote address (outside localhost) #6

Closed
balukin opened this Issue Jun 16, 2017 · 5 comments

Comments

Projects
None yet
2 participants
@balukin
Contributor

balukin commented Jun 16, 2017

Effect:
Remote API connections fail. Only localhost connections work properly.

Problem source:
API server binds to localhost instead of all available IP addresses.

Resolution:
Workaround for development purposes will be published here on Tuesday. Proper publicly available fix will follow later in June. Contact us if you need it released faster (for example, if you have product release relying on remote API coming soon).

@balukin balukin added the bug label Jun 16, 2017

@balukin balukin self-assigned this Jun 16, 2017

@mungewell

This comment has been minimized.

Show comment
Hide comment
@mungewell

mungewell Jun 18, 2017

Not dealing with remote connections, but early access to "HDMI/no-phone-needed" would really help my pyPSVR project development.

mungewell commented Jun 18, 2017

Not dealing with remote connections, but early access to "HDMI/no-phone-needed" would really help my pyPSVR project development.

@balukin

This comment has been minimized.

Show comment
Hide comment
@balukin

balukin Jun 19, 2017

Contributor

@mungewell
This will be released with 2.0 update which will be available for public testing this summer.

Contributor

balukin commented Jun 19, 2017

@mungewell
This will be released with 2.0 update which will be available for public testing this summer.

@balukin balukin changed the title from Remote API connection fail to API connections fails when used from remote address (outside localhost) Jun 19, 2017

@balukin

This comment has been minimized.

Show comment
Hide comment
@balukin

balukin Jun 19, 2017

Contributor

Workaround:
Create a .bat file next to Riftcat.exe with a following line:

start Riftcat.exe -updatessource "https://riftcat.blob.core.windows.net/updates/apiNetworkFix/feed.xml"

You will need to launch the file twice and continue using the .bat file to keep it patched to the hotfixed version.

Then alter connection scripts to connect to data endpoint (headtracking, controller, broadcast) by known IP address of the server instead of the address dispatched by control service. In the hotfixed version, control service will return *:<port>, for example *:38221 instead of localhost:<port>.

You can ignore the EndpointAddress field completely or replace * with a known IP address of PC that is running VRidge.

As an example, you would need to alter this line:

// Initialize the proxy
headTrackingProxy = new HeadTrackingProxy(response.EndpointAddress, false);

change it to

// Initialize the proxy
headTrackingProxy = new HeadTrackingProxy(response.EndpointAddress.Replace("*", remoteServerIP),
 false);

This is a temporary workaround and v3 will most likely be incompatible with it (* won't be returned in EndpointAddress string). Use it only if you need it fixed immediately for a presentation or some event.

Contributor

balukin commented Jun 19, 2017

Workaround:
Create a .bat file next to Riftcat.exe with a following line:

start Riftcat.exe -updatessource "https://riftcat.blob.core.windows.net/updates/apiNetworkFix/feed.xml"

You will need to launch the file twice and continue using the .bat file to keep it patched to the hotfixed version.

Then alter connection scripts to connect to data endpoint (headtracking, controller, broadcast) by known IP address of the server instead of the address dispatched by control service. In the hotfixed version, control service will return *:<port>, for example *:38221 instead of localhost:<port>.

You can ignore the EndpointAddress field completely or replace * with a known IP address of PC that is running VRidge.

As an example, you would need to alter this line:

// Initialize the proxy
headTrackingProxy = new HeadTrackingProxy(response.EndpointAddress, false);

change it to

// Initialize the proxy
headTrackingProxy = new HeadTrackingProxy(response.EndpointAddress.Replace("*", remoteServerIP),
 false);

This is a temporary workaround and v3 will most likely be incompatible with it (* won't be returned in EndpointAddress string). Use it only if you need it fixed immediately for a presentation or some event.

@balukin

This comment has been minimized.

Show comment
Hide comment
@balukin

balukin Jul 4, 2017

Contributor

This workaround (a bit altered because we didn't want to break backwards compatibility) is included in latest beta update (1.4.1).

EndpointAddress still contains localhost:port but you can replace "localhost" on client side with actual IP address of the server. Server listens on all available IP addresses now.

Contributor

balukin commented Jul 4, 2017

This workaround (a bit altered because we didn't want to break backwards compatibility) is included in latest beta update (1.4.1).

EndpointAddress still contains localhost:port but you can replace "localhost" on client side with actual IP address of the server. Server listens on all available IP addresses now.

@balukin balukin added this to the v3 milestone Jul 28, 2017

@balukin

This comment has been minimized.

Show comment
Hide comment
@balukin

balukin Mar 12, 2018

Contributor

Server now returns port only in endpoint response. Caller should now use remote IP address + given port to connect to data.

Contributor

balukin commented Mar 12, 2018

Server now returns port only in endpoint response. Caller should now use remote IP address + given port to connect to data.

@balukin balukin closed this Mar 12, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment