The Xena Blog

More than you ever wanted to know about MSDN Subscriber Downloads

Some design considerations for Xena 3.0:

The Table Of Contents is a known problem, and funnily enough fixing the TOC became the basis of our very major Xena 3.0 upgrade.  The TOC right now is a static toc.xml file that is around 800KB, which takes way too long to render for modem users.  My spec for the new TOC will be a maximum 5 second render time over a 56K modem - I haven't seen the technical spec for how this will be implemented, but I assume that they'll chunk layers of the TOC and pre-cache in some way.

With respect to cross-browser compatibility, this is also a priority 1 feature for the new site.  This has been a hotbutton issue for me for some time, and my requirement is to have broad cross-browser compatibility; I believe we'll test on IE, Mozilla, and Opera. 

Now, about File Transfer Manager:  FTM is a client/server application that provides robust download, encryption, prioritization, geo load balancing, and reporting.  Because we're dealing with pretty big (and growing) file sizes, FTM allows us to post a 4.7GB Visual Studio DVD image with very high confidence that it is being downloaded correctly.  We are constantly making improvements, and in the Xena 3.0 timeframe I believe we'll be working on multi-threading the client to improve download speeds further.  However, since we maintain the data centers (as opposed to using an edge network like Akamai) for Xena, a user who's 1000 miles from the nearest Xena server is going to have some latency issues.  So, in a broad sense we'll be working on performance, but I don't anticipate using anything like BitTorrent or some edge routing to deliver the several terabytes of content that we need to securely and reliably publish.

Posted: Oct 21 2004, 11:27 AM by ntmatter | with 4 comment(s)

Comments

Roy J. Salisbury @ VsDevCentral said:

File Transfer Manager: I don't think anthing like BitTorrent is needed.. But multiple threads in the client would do a lot. I have a 5MB connection at home via my cable modem and just last night was downloading a rather LARGE file from Microsoft's public servers. Using a download manager like Net Transport I was able to get around 500KB/sec. Normal downloads from the subscriber sites are usually around 120-130 (not even full T1 speeds).

So, if the File Transfer Manager used on the subscriber sites functions like Net Transport (or any of the popular ones), it will be a BIG help.
# October 21, 2004 2:48 PM

Andy (MS) said:

The issue isn't really with the Transfer Manager, it's probably with the server. When downloading from MSDN Subscriber Downloads, you're downloading from a specific datacenter in Redmond, Dublin, Tokyo, or Singapore. Many public downloads (in particular anything on the public MS Download Center) are hosted on an edge network like Akamai or Digital Island, so that a popular download exists on a hosting server very close to the user.
# October 21, 2004 2:55 PM

Roy J. Salisbury @ VsDevCentral said:

While all that is probable true, I have in the past downloaded multiple items at the same time and got the same speed on both. Here is what I did..

Start downloading Windows XP from the subscriber downloads on one computer, and then start downloading Windows Server 2003 from another computer. Both systems are using the same internet connection (cable modem in my case, but the same happens at work on a T3). Each download gets about 120-130 .. combined that is 240-260. And I can only assume that I was not the only one downloading at the time. So that tells me that either the download server is limiting the speed per connection, or the Transfer Manager just is not able to handle the speed (or both).

Here is an offer for you. Send me the source for the Transfer Manager (I'll sign whatever NDA you want) and I'll re-write the thing for you so that it can handle the multiple connections (C/C++, C#, VB, Delphi, whatever language you want). You will just need to fix the server.
# October 21, 2004 4:01 PM

Andy (MS) said:

Thanks for the offer to update FTM, I'll mention it to the download platform support teams but I don't think they'll be keen. :-). One feature that we have requested is multithreading within a download in FTM. Currently, you can go to options and set maximum threads to 2, which allows you to download 2 files at the same time. We've asked to be able to set high thread counts per file to speed the download up to the capabilities of our servers. During major launch events when we want to manage bandwidth we can regulate the number of simultaneous threads per file per customer.

A
# October 21, 2004 5:11 PM