core icon indicating copy to clipboard operation
core copied to clipboard

Requires packages.microsoft.com cdn of China

Open hzexe opened this issue 6 years ago • 17 comments
trafficstars

Problem encountered on https://dotnet.microsoft.com/download/linux-package-manager/debian9/sdk-2.2.300 Operating System: Linux Debian 9 - x64

Provide details about the problem you are experiencing. Include your operating system version, exact error message, code sample, and anything else that is relevant. -----------------------------------

Almost unable to download .net core package from China because of the speed of reaching packages.microsoft.com server。Is it possible to add CDN of packages.microsoft.com in China? :heart_eyes:

hzexe avatar Jun 15 '19 12:06 hzexe

Not sure if this is something our team controls. @dagood do you know if the install/setup area could assist with this request?

carlossanlop avatar Jul 09 '19 17:07 carlossanlop

We don't control it, but @leecow may know if the Microsoft package repository owners have some plan here.

dagood avatar Jul 09 '19 17:07 dagood

@leecow no answer since July :( do you have any updates?

carlossanlop avatar Sep 27 '19 18:09 carlossanlop

I don't have any information regarding package.microsoft.com CDNs. @hzexe - please reactivate if this is still an issue.

leecow avatar Sep 28 '19 19:09 leecow

It's still a big problem. The download speed is very slow in China.

My speed is usually less than 20 kB/s. Every time I update .NET Core SDK or PowerShell, I have to wait for about one hour.


In my opinion, there are mainly two ways to improve download experience now:

  • Reach the team that controls the package repository, and switch to a CDN working better in China.

  • Grant permissions to a mirror service like Tsinghua TUNA, and suggest Chinese users download there. Actually, there are already some discussions (tuna/issues#335), but no one has any idea on Microsoft's attitude to mirroring or the contact information of Microsoft.

I would appreciate it if this problem is resolved.

Lemmingh avatar Jan 30 '20 14:01 Lemmingh

I've sent an email to the admins of the packages.microsoft.com repos, I'll comment here with more info if I get a response.

(Note that recently, there have been frequent outages for all users of the service that is a higher priority for us at the moment, tracked by https://github.com/dotnet/core/issues/4167.)

dagood avatar Jan 30 '20 17:01 dagood

The repo team did a little bit of investigation into this. In summary, they see the value but there is no definite timeline.

The team is unable to create a VM in China to test the exact scenario you're hitting here. However, there is a mirror set up for East Asia, and they confirmed that after creating a VM in East Asia, the mirror works as expected and they don't experience slowness. They also investigated that mirror's health and don't see any issues.


I wonder if it's possible you're being routed to the wrong mirror, causing this slowness. @hzexe, @Lemmingh, can you give me the IP address you're connecting to? For example, run this command:

$ wget https://packages.microsoft.com/keys/microsoft.asc
...
Resolving packages.microsoft.com (packages.microsoft.com)... 13.91.48.226

(That IP addr is the mirror I'm being connected to--I don't know the IP of the East Asia mirror.)

I can then ask the repo admins if the IP address you're hitting is the East Asia mirror. They believe that traffic from China should go there, but they're not sure.

However, it's possible you're being routed correctly and the connection is simply slow.


  • Grant permissions to a mirror service like Tsinghua TUNA, and suggest Chinese users to download there. Actually, there are already some discussions (tuna/issues#335), but no one has any idea on Microsoft's attitude to mirroring or the contact information of Microsoft.

@leecow, can we clarify this? I assume it is fine to redistribute the .NET Core RPM and Deb packages, but potentially not ok to mirror the entire repo.

dagood avatar Feb 10 '20 19:02 dagood

@dagood I am connecting to 13.75.127.55, which is located in Hong Kong SAR, China. But I also hope there are mirrors in Beijing and Shanghai.

Resolving packages.microsoft.com (packages.microsoft.com)... 13.75.127.55

xiaoyinl avatar Feb 11 '20 10:02 xiaoyinl

Thanks for checking! I've confirmed with the repo owners that 13.75.127.55 is expected for East Asia, so it appears that the routing is happening as they expect and it's simply slow.

Note: the IP internally redirects to four mirrors, and the repo team isn't completely sure all four are healthy. They don't see any obvious signs of bad behavior. If someone (perhaps in a different part of China) has good download speeds, this may help them figure out if one of these mirrors is unhealthy--please let us know.

To make sure it's clear: the repo owners aren't currently able to set up a mirror in China, unfortunately. They do see the value, but there is no timeline as of yet.

dagood avatar Feb 12 '20 00:02 dagood

can we clarify this? I assume it is fine to redistribute the .NET Core RPM and Deb packages, but potentially not ok to mirror the entire repo.

@nakarnam - can you check if the packages.microsoft.com owners have specific policy guidance for this question?

leecow avatar May 19 '20 20:05 leecow

@leecow @dagood any updates here?

mairaw avatar Aug 11 '21 23:08 mairaw

/cc @dleeapho

dagood avatar Aug 12 '21 19:08 dagood

https://github.com/dotnet/core/issues/7239#issuecomment-1817520174

so can we use cdn.azure.cn cdn node?

or like https://github.com/microsoft/vscode-dotnettools/issues/138

@dagood

eveloki avatar Nov 18 '23 14:11 eveloki

The packages.microsoft.com team now has their own GitHub repository for issues, so I believe it's now best to ask about this at their repo so you can get the opinions of the team responsible for that resource:

  • https://github.com/microsoft/linux-package-repositories/issues/58

dagood avatar Nov 20 '23 19:11 dagood

Any progress on this? It's occasionally slow and occasionally fast, which seems to CDN cause problems.

VAllens avatar Jan 18 '24 05:01 VAllens