Beware of Using Google Or OpenDNS For iTunes
Relayman writes "Joe Mailer wanted to download an iTunes movie recently and his Apple TV told him it would take two hours. When he switched his DNS resolver settings, the download time dropped to less than 20 seconds. Apparently, iTunes content is served by Akamai which uses geolocation based on the IP address of the DNS request to determine which server should provide his content. When you use Google or OpenDNS to resolve the Apple domain name, all the requests to Akamai appear to be coming from the same location and they're all directed to the same server pool, overloading that pool and causing the slow downloads. The solution: be wary of using Google or OpenDNS when downloading iTunes files or similar large files. Use your own ISP's DNS servers instead or run your own resolving DNS server."
But I just tested this on my own by using a different source that uses Akamai: Adobe.
So I picked a file at this URL: http://ardownload.adobe.com/pub/adobe/reader/unix/9.x/9.4.0/enu/AdbeRdr9.4-1_i486linux_enu.bin
Sure enough, the initial server directed me to 72.215.224.16 with this partial tracert:
Firefox told me this would take 3 Minutes and 35 Seconds.
Then, I set my DNS to the 8.8.8.8 and 8.8.4.4 addresses and tried it again. This time I was sent to 72.246.30.19 with this partial tracert:
Surprisingly, this second server that I was directed to using Google DNS only took 10 seconds to download the same file. I did it a second time and it took 30 seconds.
Now after restoring my default DNS resolution that URL continually directs me to 72.215.224.40 and the download is as speedy as the Google DNS. If I switch back to Google DNS it now continually directs me to 72.246.30.32 so you can see that there's some load balancing going here that apparently can be divvied up by geographic location for some of their customers. Apparently Apple needs to investigate the same solution that Adobe is using from Akamai. Which doesn't consider everything from Google DNS being fulfilled from a west coast replication server?
My work here is dung.
This is a very widespread practice now. Use your own ISP for DNS.
There's some good technical discussion in the Hacker's News discussion of this issue.
This afternoon, I found a tool from Google Code called namebench which tests response times against multiple DNS servers and give recommendations based upon a number of query types. The results returned when checking the 'censorship tests' were interesting. Seems a number of sites (wikileaks, isohunt, stormfront) returned 'incorrect' results across DNS servers. I'm going to try this over the next couple of days and see if any of my browsing speeds improves.
Very criminal when you consider that you do NOT need to install iTunes just to install quicktime.
I have to ask why they are playing games with dns rather than using some kind of LB solution to direct users to the closest server(s) based on the client ip address. Is this not feasible or is it cost prohibitive; the method theyre using seems crazy to me though i fully admit to not being up to speed on high level networking design.
Their DNS server never knows your IP since if the name result isn't cached by the DNS server you are using then that server makes the request to them not your computer and hence they either see nothing or the IP of the DNS server you are using.
If some of the server pools are being overloaded while others are sitting relatively load free, source location is obviously not the best choice for load balancing. Sure, it may work most of the time but I'm sure ISP's dns server locations are not equally spaced around either. I am in VA and the Comcast DNS address I have are in NJ. I guess that is not too bad but how many people from Comcast are using those same DNS addresses?
Really? You mean on the Mac it isn't required to set up an IPhone or IPad that have no business relying on a desktop machine? You mean it isn't required I sync with it just to get Podcasts onto a device that already has internet connectivity? You mean on Mac it doesn't have a proprietary, signed procedure for syncing music to IPhone/IPod Touch/IPad, that makes it completely impossible to develop competing software without breaking the DMCA?
Sure the "ITunes experience" doesn't suck as hard on the Mac as it does on other platforms, but it still sucks. As GP says it's malware, only I would elaborate and say its malware that malicious to an entire industry.
I've used our university's DNS servers as primary for over a decade, with whatever my current ISP is as secondary. I haven't had any complaints.
#DeleteChrome
They only find out your IP address after it's too late.
If only ignorance is criminal too.
Maybe at one time, iTunes was the only way to get Quicktime, but if that's true, that was years ago.
http://www.apple.com/quicktime/download/
I think you'd find some people saying QuickTime is criminal too, but I think that's a different discussion.
whose DNS were you using?
In soviet Russia, God creates you!
That's true. However they do require you to install quicktime in order to get the codecs, unless I'm missing something. And for whatever reason Apple insists on not using any native widgets. Which means that not only are you installing crapware, but it also looks ugly on top of that.
It wouldn't and really shouldn't. CDNs are there to ensure that the least amount of infrastructure is used for each request. Meaning that they try to put the server as close to your physical location as possible. If anything, net neutrality would encourage this as it would be easier to have a CDN covering both Qwest and Comcast in a given region or whatever the options are in your area.
I use to setup my own DNS at home and casually use forward zones when needed. I started this when ther was that issue with redirecting non existant names.
Sure, not every one should do this as it stress load root servers and some ISP may redirect UDP/TCP 53 to their own servers. BTW, that's still my way of using DNS.
Léa Gris
It is actually a pretty complicated problem, finding the IP address of the nearest host based on a domain name, solved in a fairly elegant way.
The only problem here is that you are being passed the address near Google instead of your ISP, which means that you miss out on the benefits of finding a host nearby that is only a few hops away.
Microsoft does this too. After scratching my head over the past several weeks trying to figure out why I cant download M$ files worth crap half the time, this appears to be why.
Elegant? Misusing DNS to make a CDN faster isn't elegant.
You don't need to install iTunes to install QuickTime. Sadly, you do need QuickTime to install iTunes. Which is the lessor evil depends on your needs, but I'd be thrilled to have iTunes alone without QuickTime, Bonjour or the host of kernel mode crap it installs.
Give a man a fish, he'll eat for a day, but teach a man to phish...
Right... Without DRM, but with a watermark (in other words, if you download a Miley Cyrus song and share it, anyone else who gets access to it can track it back to you)
That being said, I have a lot of trouble getting upset over the fact that purchased content is watermarked. As long as I'm not distributing the content, who cares?
Give a man a fish, he'll eat for a day, but teach a man to phish...
So the moral of the story here is not that Google and OpenDNS services are bad, but that Apple's iTunes QoS methods are of "questionable quality" - at best.
How did this make Slashdot's frontpage, again? Maybe this should be filed as a bug report to Apple (do they read those?) instead.
~/ssh slashdot.org ssh: connect to host slashdot.org port 22: too many beers
Your computer uses that answer to contact the server and download whatever. If it was given the wrong server, it's too late now.
Why is that too late? See the IP address, issue a redirect to the appropriate server. In HTTP that's as simple as issuing a 302 response and a Location: header. (I haven't Wiresharked iTMS to see how it's connecting, but it would be a dead simple change to the protocol to insert a handshake step that occurs before the substantive transfer begins. Overhead would be negligible.)
geek. lawyer.
Seems like it would be useful to use multiple DNS servers and then choose whichever one has the fastest download and abandon the other connections.
Do any browsers/OSs/whatever have this feature? As I understand it, the secondary DNS feature only uses the secondary server when the primary server is down.
It must be Apple's "magic" that's causing the trouble.
No, it is not Apple's fault. Anyone using Akamai would have the same problem. I think Microsoft use them for Windows Updates too.
I already knew this, but now it makes me think why not we instead use HTTP redirection strategy? That is, say the client hits the server directly at http://example.com/very-large-file.zip, the server detects the client's IP and permanently redirects it to http://[location].static.example.com/very-large-file.zip, where static.example.com is a subdomain managed by Akamai and [location].static.example.com always resolves to CDN node nearest to the specified location regardless of the client's IP address.
It's not too late at all.
The HTTP server can redirect you based on your location.
This applies to tons of GEO-optimized services and has been this way since day one. Really, how is this news?
Which is the lessor evil depends on your needs,
Well, since neither Quicktime or iTunes is leased to you, I guess that means neither is a lessor evil.
... and then they built the supercollider.
No, it's not particularly elegant. But on the other hand, split-horizon DNS is nothing new or magical either. Nor would I classify it as "abuse". The capability has been there since the early days of BIND.
In the DNS trade, we refer to it under the category of "stupid DNS tricks"
That said, it does have some significant advantages over other techniques.
#1, It's protocol-independent. Sure you can do intelligent redirects with HTTP, but not everything in the world is HTTP
#2, Even with HTTP, in order for it to work, you have to now change the name of the server, and often the links to internal content. Your initial request to www.domain.com will now have to be redirected to hostx.domain.com or www.location.domain.com etc., and links on the pages to content servers will also have to be altered. This can be confusing to end-users, and may require additional SSL certs. It's also a code maintenance issue.
#2a, While the renaming seems trivial on first glance, it has HUGE implications for search engines, etc, since those "local" servers will get indexed instead of a generic name
#2b, It also means that a calculation will have to be made by the web server deciding where to redirect you to, then the actual redirect, increasing load and latency. DNS solutions are "pre-computed" and thus do not have similar issues.
#2c, If you solve 2a by checking every request at every location, you make 2b much worse
#3, It's simple.
Downsides:
#1, Third-party DNS recursive services throw it off. (There is a proposed RFC that would allow for such recursives to pass the originating network in the request)
#2, It makes DNSSEC a right royal PITA (Much more than it already is)
Indeed. HTTP might be a bit slower and not benefit from the ISP's DNS caching, but in conjunction with the DNS method it would provide an acceptable correction method. Rather wait 1 more second for the download to start then to download at painfully low speeds.
Fair enough.
Give a man a fish, he'll eat for a day, but teach a man to phish...
Quicktime has been around a lot longer than iTunes (but it was never less of a resource hog as far as I remember).
http://en.wikipedia.org/wiki/Quicktime#QuickTime_1.x
Pretty sure Apple is using all HTTP Live Streaming at this point, which in fact is all based on HTTP...
Also I have worked with a lot of applications that stream or play media now, and generally it's been done over HTTP - I'd say that's more the rule than the exception.
And if an HTTP client can't follow redirects it's not really an HTTP client - that's pretty basic stuff, I can't fathom there is anything that wouldn't obey a re-direct (unless it was doing so on purpose).
"There is more worth loving than we have strength to love." - Brian Jay Stanley
The moral the the story would appear to be that more people on Slashot need to read up on what CDN's are and who runs them.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
1.2.3.45 same as my luggage uses.
rewriting history since 2109
I may have to sniff some traffic going to Apple. For some reason their software updates kill our filters. I wouldn't be surprised to find they've made a 'custom' HTTP for themselves.
Six months ago, I was the owner of mini-Mac, iPad and a iPhone. Now, I no longer have the Mac, (back to windows and mostly Linux), have a Galaxy S Captivate, and the newest device is a eLocity A7 Android tablet. I will not say that there haven't been some bumps in the road, but I will say I'm happier overall.
Now, I would still recommend a Mac to some of my Family/Friends who don't like configuring their computers. In fact as one of the major techies in my family I encourage them all to adopt Macs, because then my life is a lot easier!
-My mistakes are just those, please accept my apologies. Tks
With a little effort, you can set up BIND on your own system.
Wow, had to stop and fap to your own fanfiction.
Still waiting on Serviscope_minor to wake up to fucking reality and realize that Jessica Price isn't going to fuck him.
Most of Akamai's caching platform is based around DNS for location awareness. This is because DNS (in most cases) can be easily anycasted (since it's stateless when all done over UDP) vs trying to anycast tcp connections done with HTTP.
...the tool from Geek Squad copies your music while your box is in the shop?
I realize this is Slashdot and your head probably just exploded at the thought of *you* going to Geek Squad - but there's a simple and glaringly obvious problem with watermarked media files:
They are, ultimately, completely useless in terms of actually determining wrongdoing.
More info on my above point. If Akamai were to use HTTP instead of DNS for load balancing, complexity would increase in having to manage redirect clusters, as you couldn't anycast them over UDP like you can with DNS.
RFC 1546 - Host Anycasting Service
How UDP and TCP Use Anycasting
It is important to remember that anycasting is a stateless service.
An internetwork has no obligation to deliver two successive packets
sent to the same anycast address to the same host.
Because UDP is stateless and anycasting is a stateless service, UDP
can treat anycast addresses like regular IP addresses. A UDP
datagram sent to an anycast address is just like a unicast UDP
datagram from the perspective of UDP and its application. A UDP
datagram from an anycast address is like a datagram from a unicast
address. Furthermore, a datagram from an anycast address to an
anycast address can be treated by UDP as just like a unicast datagram
(although the application semantics of such a datagram are a bit
unclear).
TCP's use of anycasting is less straightforward because TCP is
stateful. It is hard to envision how one would maintain TCP state
with an anycast peer when two successive TCP segments sent to the
anycast peer might be delivered to completely different hosts.
The solution to this problem is to only permit anycast addresses as
the remote address of a TCP SYN segment (without the ACK bit set). A
TCP can then initiate a connection to an anycast address. When the
SYN-ACK is sent back by the host that received the anycast segment,
the initiating TCP should replace the anycast address of its peer,
with the address of the host returning the SYN-ACK. (The initiating
TCP can recognize the connection for which the SYN-ACK is destined by
treating the anycast address as a wildcard address, which matches any
incoming SYN-ACK segment with the correct destination port and
address and source port, provided the SYN-ACK's full address,
including source address, does not match another connection and the
sequence numbers in the SYN-ACK are correct.) This approach ensures
that a TCP, after receiving the SYN-ACK is always communicating with
only one host.
Emphasis mine.
If HTTP was used instead of DNS, Akamai would have to have a redundant HTTP redirect cluster to manage the redirections. But you can't have one cluster, you need several for redundancy and speed, spread across the world. Also, you can't use anycast with TCP like you can with DNS, because it's TCP based, which means you lose load balancing and redundancy at the IP protocol layer.
DNS was and still somewhat is easier. No one really envisioned Google doing DNS and it taking off I think.
The first suggestion is just no longer an option, for so many reasons, all of them based on lack of trustworthiness in this climate of corporate dominance and machination. I was using OpenDNS for several years, but recently I started using TreeWalk to host my own modest DNS server. Seems to work fine, and I don't even notice it's there.
Load balancing based on the DNS resolver is so 1999! Even when it works, it works by chance, and does not test the actual speed between your PC and the potential servers. Compare that to Bit Torrent, which actually tests the speed of the downloads. You really wonder why Apple, and Akamai, would not use some kind of torrent technology!
Elegant is over-rated. DNS is a great place to implement some good value trickery for 99.99% of customers.
is iTunes?
One question: do you think there's more information in the IP address of the incoming HTTP GET request or in the IP address of the incoming DNS query?
While everyone is using a browser, very few are running a DNS server. Provided that it's properly configured.
Maybe Computers will never be as intelligent as Humans.
For sure they won't ever become so stupid. [VR-1988]
It's too late for Akamai's form of transparent mirroring which doesn't hit their customer's servers if they already have the data they need. The insertion of Akamai's servers into the mix is done by substituting IPs and doesn't take place at a higher level of protocol.
Of course they ultimately have to serve up data to the requesting IP and they could verify that their original geo-location was accurate. Maybe someone should patent that idea quick since Akamai hasn't seen fit to implement it yet.
I am becoming gerund, destroyer of verbs.
There are dozens of free dns services. Akamai knows this problem. But for some reason, they don't take appropriate measures.
Their DNS can serve an IP based on the geo-location. If visitors are using a dns server that is known for hiding the actual location, I would suggest serving the IP of a redirect-only HTTP server. The client connects to this redirect-only HTTP server and the server returns a "301 Location:" header based on the clients actual IP/location.
This will make the initial connection for users of Google DNS/OpenDNS a little bit slower, but then allows the available bandwidth to be used optimally.
.sig: No such file or directory
I'm surprised no one mentions the above free/public/fast DNS resolvers :-p
Right... Without DRM, but with a watermark (in other words, if you download a Miley Cyrus song and share it, anyone else who gets access to it can track it back to you) That being said, I have a lot of trouble getting upset over the fact that purchased content is watermarked. As long as I'm not distributing the content, who cares?
There are of course all kind of conspiracy theories around, but the fact is that two things are different in your downloaded files than in my downloaded files: The Quicktime atom for "creation date" which is - guess what - set to the time when we each download the file, and there is information so that _your_ downloaded file will turn up in the "Purchased" section in iTunes on your computer. This is not a watermark at all. It's just iTunes not carefully removing forensic evidence that could be used against you.
If anyone cared there would be an anonymiser app for this.
But anycasting doesn't get the IP address too late?
Change is certain; progress is not obligatory.
As someone who has setup TCP anycasting. Just ensure that your anycasting routing is stable, that prevents pretty much any 'hop' issues.
See also, http://www.nanog.org/meetings/nanog37/presentations/matt.levine.pdf
Change is certain; progress is not obligatory.
this website http://ip-address-lookup-v4.com/lookup.php and this one http://ipxml.info/myip/?ip=213.251.189.203 are able to figure out my location correctly no matter what DNS server I use?
maybe time for akamai and company to change the way they figure out an ip address's geo location.
Amazon's MP3s are plain old MP3s which require no proprietary software that could delete your MP3s.
The poster is referring to the GUI I'm sure - in the most recent release of Safari for Windows they have now dropped that (finally!).
The Java analogy is not so far off, even if no Java style VM is involved, it's a throwback to OpenStep on Windows which does some target platform abstraction. Apple keep their own cross platform versions of the development tools running on other platforms - Interface Builder (now known as "Xcode") ran on Windows and on both Windows and Mac could cross compile (for Win/Mac/Solaris).
The approach Apple use for bundling QuickTime and iTunes on Windows is technically very sensible (of course they should re-use components as dependancies).
The problems are (1) the UI for iTunes is not fully native (2) the Apple Software Update app for Windows (which is a clone of the Mac version) is obtrusive to an unwarranted degree and (3) QuickTime has some obnoxious options selected for default install, and while being great on Mac OS X 10.6, sucks big time on Windows (to the extent no-one would *want* it as their default media player).
People still use iTunes?
That's true. However they do require you to install quicktime in order to get the codecs, unless I'm missing something. And for whatever reason Apple insists on not using any native widgets. Which means that not only are you installing crapware, but it also looks ugly on top of that.
The widget thing is just stupid. Hell, last time I checked (a long time ago) Safari was doing its own text rendering on Windows. Bleah.
Of course, Firefox annoys me for the same reasons. Oddly enough, most /. users don't seem to include its GUI in their rants.
You're special forces then? That's great! I just love your olympics!
Just in case you didn't realize, on Windows you *can* uninstall Bonjour. iTunes will happily re-install it every time you upgrade, but it's not necessary for it to stay installed.
+1
The talk about UDP is not relevant since they still could use the DNS geolocation for the UDP connections. And I guess that most of their traffic is http anyways.
I always use a local dns recursor server so I point my dns settings to 127.0.0.1. I can only see advantages privacy and performance-wise. The kind of problem described in this article seems to be another advantage to my apporach over using an external DNS server, but at the same time I rarely see anybody recommending it. What are the disavantages of using things like pdns-recursor?
The problems are (1) the UI for iTunes is not fully native
As I understand your post, "native" means "using one of the GUI toolkits included with the operating system distribution". In that case, KDE apps aren't "native" on Ubuntu, no full screen game is "native", and Microsoft Office 2007 isn't "native" either.
Better solution - How about Akamai watches where the actual HTTP/FTP request comes from, rather than the DNS? That should get you closer to the client.
I'll start using my ISP's DNS servers as soon as they figure out how to properly configure/maintain/run them. Until then, OpenDNS and GoogleDNS it is.
"Work is the curse of the drinking classes." -Oscar Wilde
Why not express it more clearly then? And then go on the four paragraph rant.
Something like:
When you make a DNS query your IP address is not exposed to the server making the geolocation decisions. All it gets is the IP address of the DNS server you are using, and if the result is cached already it doesn't see the request at all.
You missed the huge box notifying you that all your music would be deleted because the iPhone wasn't paired with that machine? You just clicked the continue button, labelled "restore iPhone" (the buttons are marked by task, not with "ok").
iTunes is very clear about when it will delete the music on your iDevice, and asks you clearly with a detailed warning when you attempt to sync an iPhone with a copy of iTunes that is not it's "home" base.
If you missed that, then you just don't read warning boxes that require user action. iTunes will not delete your music without user authorisation.
The originating network of the client.
Caching would not have to be turned off, but it would get a lot more complicated.
Note that the draft expired, but I expect someone will eventually resurrect it.
EDNS Client IP
That's not how Google DNS or the other open DNS sites work with the Content Delivery Networks. Here's how the process really works:
http://www.zdnet.com/blog/networking/changing-dns-probably-won-8217t-help-your-video-streaming/467
The bottom line is that changing your DNS is unlikely to help with your video-streaming, and if it does, it's pretty much a matter of you lucked out.
Steven
You mean it isn't required I sync with it just to get Podcasts onto a device that already has internet connectivity?
I've never required a sync to download podcasts... heck I've done it from 3G.
"I like to lick butts!" by MobileTatsu-NJG (#32700246) (Score:5, Informative)
I'm just amazed that a slashdot reader isn't savvy enough to backup their music to something more reliable than a mobile phone.
W..w..W - Willy Waterloo washes Warren Wiggins who is washing Waldo Woo.
I sat in on that presentation (and am on the NANOG mailing list). I agree that it *can* work, but you can't rely on simple geographic diversity for route stability with a platform the size of Akamai's. Not enough knobs to twist when things break (although it seems to be working great for CacheFly).
Excellent presentation, btw.
Going to be at NANOG51?
Not true! I just had this issue the other day. My AppleTV was telling me it was going to take 3 hours to download an episode of The Office. I rebooted it twice. Same thing. I manually set the DNS to my own Ubuntu Box (instead of OpenDNS it was getting from my Cisco 891), rebooted and the download took 2 minutes and 50 seconds (50/50 FiOS). This is clearly still an issue.
Mike @ The Geek Pub. Let's Make Stuff!
Technically this is true, but I'm more annoyed by QuickTime's stream of vulnerabilities and the potential instability of having unneeded kernel modem drivers.
Constantly uninstalling something every time iTunes has an update isn't worth the hassle, nor is pulling apart the iTunes installer and beating it into installing just iTunes without Bonjour every time.
Bonjour is the one component that doesn't really annoy me, if only because it occasionally gets used (or at least some iPhone apps can use it to find a PC, and it's sometimes easier/lazier than entering IPs)
Give a man a fish, he'll eat for a day, but teach a man to phish...
For the record, I loathe iTunes/Quicktime as well.
Me too, but iTunes is a requirement to use an iPhone (call me whatever names you want, but I have WM6, iOS, BlackBerry and Android here. My iPhone is the only one I actually carry and use)
QuickTime isn't nearly as obnoxious as it used to be. It does still steal a few file associations upon installation but once you tell VLC to take back what it supports, QuickTime is mostly a "install it and forget it exists".
Gone are the days where QuickTime would run in the tray and take up CPU and memory despite the fact that you'd never actually used it.
Still, I'd happily give up iTunes' lackluster media playback capabilities entirely if I could lose QuickTime in the exchange.
Give a man a fish, he'll eat for a day, but teach a man to phish...
In fact, there are quite a few people out there using Anycast for TCP-sessions. It's really a matter on what timescale you're looking at. The networking guys see TCP as something to use for long-living connections - e.g. a BGP session running for days, weeks or even months. A flapping route in this setup will result in a broken session. But: what does this really mean to you? If your CDN distributes downloads which are "done" within a few minutes, such a rarely flapping route will result in a few broken sessions once a day out of millions of downloads successfully served. Compared to issues like non-working DNS, overloaded servers and filled lines, that's nothing and can actually enhance the overall CDN service.
A nice paper to read is this one from Matt Levine. He's working for a CDN provider using TCP-Anycast for years now and sums up the most important issues on TCP-Anycast.
Basically the most important one is that your anycasted servers really have to be spread far enough so that flapping routes at some peering point won't matter. As a rule of thumb, put one CDN loadbalancer on the US east coast, one to the US west coast, another one to western europe, one to Australia and one in Hong Kong. If you'd like to put multiple CDN loadbalancers to one continent, leave space between them, e.g. one box for each country/state.
My point was, I'm tired of the idiosyncrasies of the Mac world. Why do I have to use iTunes? Why do I have to jump through hoops to sync a damned mp3 player with a new computer? Why can't I sync it with more than one computer? I'm pretty sure there are work-arounds, however I thought Macs and Apple products were just supposed to work?
seriously, I didn't really lose anything truly. Maybe a couple of songs. I do back up, in fact I have a backup server here at the house. I just didn't like syncing my phone all of the time. If apple allowed wireless sync, perhaps then it would be more convenient. Of course I really was just annoyed at how my stuff behaved. In fact the last time I lost some songs, Apple reset the download flags and let me re-download them. I suppose I could chalk up the wretched, twisted policies to the Music Industry, who really want us to buy multiple digital copies of the same song to play on multiple devices.
In our recent study, that involves vantage points in more than 50 commercial ISPs and content requests for around 10,000 hosts, we observed that the location of DNS resolvers break the assumption made by CDNs about the vicinity of the end-user and its DNS resolver. Moreover, we observed that third-party DNS resolvers do not manage to redirect the users towards content available within the ISP, contrary to the local DNS ones. We do believe that this problem is not limited to iTunes but may effect the end-user experience when downloading CDNized content that is already a significant fraction of Internet traffic. You can find more about our comparison of DNS resolvers in the Wild here: http://www.net.t-labs.tu-berlin.de/papers/AMSU-CDRW-10.pdf You can find more about our study on the effect of third-party DNS resolvers in content delivery here: http://www.net.t-labs.tu-berlin.de/papers/PFASF-ICDUPADI-10.pdf To better understand DNS and its performance, we would like to scale up the experiments and for this we are seeking your help. If you are willing to participate in this effort, please go to the following link: http://www.fg-inet.de/ Download the script that can be found in the download section of the website, and run it from an Internet connection provided by a commercial ISP, e.g., at home. The typical duration of the experiment is around six hours. All major operating systems are supported (Linux, Mac OS, Windows etc.). Once the experiment is done, please upload the traces on our website: http://www.fg-inet.de/upload.php Our script performs DNS queries for a number of predefined hosts. This list is included in plain text in the download packages. The traces collected with our program do not interact with any of your browsing or download history or activity. The additional bandwidth consumption and CPU load due to the experiment are negligible. The traces collected on this website will be kept confidential within the project and will not be distributed to any third party, nor shared with any third party. You also have the option to make them accessible to the research community if you wish so.
I just didn't like syncing my phone all of the time. If apple allowed wireless sync, perhaps then it would be more convenient.
I agree, and I have to wonder why they don't allow this. The only thing that I can fathom is security, or maybe speed. Come to think of it, it is probably speed - even a 16GB iPhone would take something on the order of 4 hours to do a complete sync. That much use of the wireless radio would probably destroy the battery time :)
I suppose I could chalk up the wretched, twisted policies to the Music Industry, who really want us to buy multiple digital copies of the same song to play on multiple devices.
They're all in it together :)
W..w..W - Willy Waterloo washes Warren Wiggins who is washing Waldo Woo.
Why do I have to use iTunes? Why do I have to jump through hoops to sync a damned mp3 player with a new computer? Why can't I sync it with more than one computer? I'm pretty sure there are work-arounds, however I thought Macs and Apple products were just supposed to work?
That's the rub... there is a real engineering tradeoff between "choice" and "just works". Apple is not magic, but they are pretty good at making a limited set of choices do a respectable job for a large number of people. The tradeoff is that it gets frustrating when you stop drinking the kool-aid.
Windows is the other side... almost infinitely configurable and the ecosystem is damned cheap - but you pay for it by being the family IT guy. All that choice comes at the expense of complexity.
W..w..W - Willy Waterloo washes Warren Wiggins who is washing Waldo Woo.
Well, there is a third choice. Linux+Android. Not pretty at times, but boy does it work. Considering the alternatives........
I didn't mean to slight Linux - it is of course a choice, and it is even more complex and configurable than Windows.
W..w..W - Willy Waterloo washes Warren Wiggins who is washing Waldo Woo.
to use a car analogy:
Windows: Get a pretty good basic car, and start adding up the options, each of which will cost.
Mac: Get a really good car, but everything is pretty much standard. No Choices.
Linux: Here's a pile of parts, and a bunch of tools. Go ahead, make your own damn car.
The "solution" that I've settled on at the moment is to use a combination of systems. I have a dual-boot Windows/Linux homebuilt for the wifey and for that occasional program/file that you simply must run on Windows. I have an Apple laptop and desktop - the desktop mostly used as a server. I'm in the process of setting up a freebsd (well, FreeNAS) file server to replace the Apple desktop, which is now about 6 years old.
I'll probably wire SOMETHING up to the TV again, but it obviously won't be the FreeNAS box :)
W..w..W - Willy Waterloo washes Warren Wiggins who is washing Waldo Woo.