Unable to refresh package manager list since early November (China specific?)

bitinn · November 23, 2018, 10:48am

maximeb_unity:

Hi @bitinn ,

Unfortunately, system proxy settings are not yet supported.

Setting persistent environment variables on MacOS is not trivial (as it depends on the OS version), and that approach is not very good practice in the first place as you never know what other program/app would be affected by setting such a variable. Therefore the best advice I can provide for now would be to create a small shell script to launch the Hub with these environment variables. Afterwards, they will automatically be passed down to the Unity instances, and the Unity Package Manager processes launched in turn.

To create that script, open a Terminal window and copy/paste the following snippet after replacing “proxy-url” with your own proxy info:
echo '#!/bin/bash
export HTTP_PROXY=proxy-url
export HTTPS_PROXY=proxy-url
nohup "/Applications/Unity Hub.app/Contents/MacOS/Unity Hub" &>/dev/null &
' > launchHub.sh
chmod +x launchHub.sh
You can then move that file to a more convenient location (e.g. your Desktop) and double-click it to launch the Hub with the proper environment variables set. Alternatively, you can execute it from a terminal with the same effect.

A few caveats:

If the Hub is already running, the script will just bring it into focus without relaunching it, so it will not update the proxy settings if you change them. You need to close the Hub first.

If you double-click the script, it will open a Terminal window and leave it open. This can be changed in the Terminal.app preferences.

Feel free to edit the script to remove either HTTP_PROXY or HTTPS_PROXY, or change the path to the Hub installation. Spaces in the path require you to leave the double-quotes around the path for the script to work.

Regarding your last two questions about ping reachability and performance from China:

You’re right that the Bintray servers do not respond to ping.

The main URL packages.unity.com is the endpoint to reach the metadata service; packages are downloaded from hosted CDNs which should, in practice, be much closer to your location, but I don’t know the specifics of the routing rules or algorithms used. YMMV.

Thank you, I have created the launch script and observe that UnityPackageManager is finally going through my proxy (I have a client that can look at what requests are passing through this proxy), and with proxy enabled, I can see the list is now refreshed properly.

3920218--334501--Screen Shot 2018-11-23 at 18.10.04.png

But if I set the request to go directly, I can see around 50% of requests to download.packages.unity.com, which is an CNAME alias of dl.bintray.com, failed due to timeout:

3920218--334498--Screen Shot 2018-11-23 at 18.08.00.png

Since the domain download.packages.unity.com itself is accessible, I was able to test with my browser and confirm the same behavior (direct access failed, proxy access did see the package list output as HTML).

So perhaps this is a regional network issue. I don’t know, I have tested it with some local tools, here is the overall result from the 3 major ISP in China:

3920218--334507--Screen Shot 2018-11-23 at 18.39.02.png

And China Telecom in particular:

3920218--334519--Screen Shot 2018-11-23 at 18.38.42.png

Here is the result cache:

https://www.boce.com/tool?type=get&taskId=e9d25d000e5fc62ce8691111ecd78477

Hopefully you can work with local partners to check if this is indeed an issue or just isolated incidents. I suspect the problem might be more widespread.

(My estimate: if the default timeout is set to 10s and the average response download time is ~8s for my region, then 50% request failure rate isn’t that unimaginable.)