1 / 8
Dec 2013

I sell a lot of digital downloads and nearly 100% of all complaints come out of Great Britain. I can send a new link directly to my server as an alternative and it works perfect for the customer. It's not the customer's ISP or internet connection. My server is in Utah. A long way from GB.



Ejunkie should contact Amazon S3 about the poor service coming out of GB. It makes us ALL look bad and unreliable.



The next most common complaint comes out of Australia, but not as often.

  • created

    Dec '13
  • last reply

    Jan '14
  • 7

    replies

  • 1.9k

    views

  • 2

    users

  • 3

    links

Thank you for bringing this to our attention; I will refer your report to Development for further research and action.

12 days later

I have a work around for this problem. I did a release yesterday and I now send the customer 2 download links. 1 to Amazon S3 and 1 to my server. I'm hoping they will get their downloads now without the frustration.



This week I had more trouble. Another customer from London couldn't download no matter what. It would download about 70mb and then drop it. I gave him a link to my server and he downloaded without any problem.



Another one with a similar problem was from Poland.



Since I started using ejunkie in August, I would safely say I have had more than 50 customers that have had this problem. Very few were from the US. They were always in Europe or Australia. Mostly GB.



I have proven to myself without any doubt the problem is Amazon S3, not the customer's computer, download program, nor the ISP. If that was the case, why does my server work so much better on the same computer? It's 1000's of miles away.



1http://www.e-junkie.com/ej/trouble.downloads.slow-stalled.htm1



Shifting the blame to the customer is not a good policy. There are obvious problems with the Amazon S3 servers in Europe and they need to be addressed. Do not stick your head in the sand and ignore it. Amazon S3 is costing me customers and respect. Not to mention some customers are telling me that ejunkie sucks and blame you for the downloads. The average person does not understand what is going on. They just see your name plastered all over the slow or failed downloads. Consider that as well.



You should consider a choice in other cloud platforms before looking into yet more payment options.



Using my server 100% of the time for my downloads is not an option. The traffic and the constant downloading of a 450mb files would drag my server down too much. My customers are all over the world and that is not a realistic option.

Here's how Development responded when I brought this matter to their attention:



S3 is not a CDN; when they download from it, it comes from the particular S3 site we've uploaded those files to (which currently is going to be an Amazon data center in northern VA). I've done some preliminary work (i.e. unfinished) in adding a CDN layer (CloudFront specifically) to that process, but there's a cost issue there such that we can't just throw all downloads through CF without running up our bandwidth costs; if we do it selectively and correctly, it could actually lower our bandwidth costs. But it's a major project and it seems like there's always something more critical in the big picture of all our internal and our sellers' wants/needs.



As for getting better performance from his server in Utah, that's all about the particular peering details between different ISPs. It very well could be the affected UK ISPs are throttling downloads from whatever peer network the s3 traffic ends up coming from because it costs them more... the situation may very well be reversed from other locations.





In summary, we're aware that reliable and fast connectivity to our particular S3 server farm can be an issue for certain ISPs depending on which upstream networks they use to connect to the Internet at large, but the remedy for that is a major and cost-sensitive undertaking, while other projects of broader impact to most/all buyers and sellers using our service have taken precedence lately.



One thing to bear in mind about providing direct links to your server is that unscrupulous buyers could share that link URL with others who could then download directly from that URL indefinitely, whereas we issue each buyer a unique link that expires after the max. Attempts or Hours you define in the product's settings. Rather than providing that fallback link to all buyers, you might simply offer an invitation to contact you in case of download issues (with a link to your email address or contact page), then provide your server link to those buyers personally. If you'd prefer to continue providing fallback links to everyone, it would at least be a good idea to change that file's location/URL every so often, so any old fallback links floating around out there would stop working.

I don't think I explained it well enough.



I created 3 products. One that leads to Amazon S3 and one to my server as a redirect. The third one is a bundle that contains the other two as the product I actually sell. According to your policy the redirect should be protected, so there isn't simply a link in the download as a back-up. I put an empty index.html file in the directory with the files like you suggested in another thread.



I was under the impression that you were using a CDN type system. Now I see why people in Europe are having so much trouble. It should be stated that all of our files are stored in one Amazon data center located in the United States. It isn't obvious that is what is actually happening.



I understand the problem better now, so I can try to figure out ways around it without my customers having a bad experience.

We can only control expiration of the unique link we provide each buyer to access the Redirection URL, but the act of redirection itself necessarily exposes that URL in the buyer's browser, which we cannot protect. We actually recommend against using Redirection to an actual file URL, for that and other reasons explained here:

http://www.e-junkie.com/ej/trouble.redirection.download.htm



If you wish to continue using the bundle method to offer all buyers a fallback link using Redirection, it would be more reliable to redirect to another download page on your site (or even a third-party file-hosting service) where a link to the file is presented.

Not redirect. I meant to say hosting the file on my own server with the single file download option. That's doesn't allow them to see the URL, does it?

Actually, when you set up a product using Single File Download with a Remote Product File URL, the buyer never downloads directly from your remote server. Rather, our server pulls the file from yours and streams a copy to the buyer from our Tucson datacenter (for the first/earliest downloads) or from our Amazon S3 provisions (for subsequent downloads of the same file once we have a copy synced from our server to there). This is how we cloak your remote URL and enforce your link expiration settings. This help page section explains how this works in more detail:

1http://www.e-junkie.com/ej/help.file-downloads.htm#remote1



Thus, there should be no difference in download performance between files uploaded directly to us vs. one hosted at a Remote Product File URL.