Net4TV
Front
News
Features
Op n' Ed
Voxpop
Community
Archive
Subscription


Switch background color
Feature
All About "Remote Loading" and How to End It


By Dudette
(February 27, 2000)

When GeoCities suspended hundreds of WebTV users for a "remote loading" violation of their Terms of Service, many of them wrote to us and asked what it meant, and how they could avoid it. Remote loading is sometimes called "linking in" graphics or audio files. In this article, we'll try to explain and to answer some of the most common questions.

Everything Has An Address

Everything that's available on the World Wide Web has an Internet address, which is how our browsers (PC or WebTV) are able to find it. Even if you don't build homepages, you're already familiar with some Internet addresses. Here's what the various elements mean, using Net4TV Voice as an example:

The address (URL, or Uniform Resource Locator) of this page is: http://Net4TV.com/voice/story.cfm?storyID=xxxx

http://
This means that the page is provided by a web server, because it's using Hypertext Protocol. That tells your browser how to ask for it.
Net4TV.com
This is the domain name of our site. The "real" address is a string of numbers called an IP (Internet Protocol) number. When you enter "Net4TV.com," the browser (or WebTV proxy server) looks up the name in an Internet directory called a DNS server and gets the number. We use names in the address, rather than the actual number, because they're easier for people to remember, and also so that if the number changes, we can change it in the DNS server but don't have to change the domain name.
/voice/
This is the path to the directory where the file (the page you're looking at) is stored. In the case of a GeoCities site, for example, /Heartland/Hills/Address_Number is the path.
story.cfm?storyID=xxxx
This is the actual file name -- it could end in ".htm" or "html" for web pages, ".GIF" for GIF images, ".MID" or ".MIDI" for MIDI files, etc. In our case, we serve our stories from a database using a program called ColdFusion. The ending ".cfm?storyID=xxxx" tells the ColdFusion engine to make a web page by putting the story with the ID number XXXX into a template, before giving it to the web server to send it to you.

How Your Browser Shows a Page

All of the graphics that are in a web page also have an address. When your browser receives the HTML page (our CFM pages are also HTML pages to the browser), it reads it and says "oh, I need these graphics files... 'logo.gif' and 'picture.gif'... in order to display this page."

In the case of Net4TV, all of our graphics are on the same server as the web pages -- that is, they have the same basic website address (domain name). So, your browser asks our server again -- "would you send me the graphics files named (filename) that you have stored in (this path)?" When it receives them, it puts them in the page that it is showing you. Here's an animation that shows you how that works.

<IMG src="http://www.net4tv.com/voice/Resources/dialup.gif" width=400 height=200>

What Is "Remote Loading?"

Fundamentally, "remote loading" means calling resources -- GIFs, JPEGs, MIDIs, and other files -- that are stored on a different server or website than the one where the web page is stored. Remember, everything on the web has an address, and if you know that address, you can call the file by using it.

Here are two example images, with their addresses as they are in the page source code:
<IMG SRC="graphics/newvoice3.gif">

Because the graphics are in the same place as the web page that's calling them, we're using a "relative" URL -- an address that's relative to the page that is referencing them. When your web browser receives the HTML page and asks for the graphics, it just tacks on the relative reference to the page address to request the full address of the graphics: <IMG SRC="graphics/story/newvoice3.gif">

<IMG SRC="http://www.iacta.com/graphics/carrier.jpg">

This graphic is on another server. The complete address of the file is necessary in order to call it.

The Net4TV Voice banner is not being remote loaded -- it is located in the same website as the Net4TV Voice page that is calling it. The "Carrier" graphic is being remote loaded -- it is being called from another website on a different server and domain (in this case, from our company site).

Here's an animation that shows what happens when a page uses remote loading. Sometimes, some of the servers holding the "remote" resources don't answer or can't find the file, which slows down the page display and causes "broken" images:
<IMG src="http://www.net4tv.com/voice/graphics/dialup.gif" width=400 height=200>

If you are remote-loading graphics into your web page, the other web servers have to be called for the graphics every time someone views your page. If 100 people visit your page today, and you are remote-loading a graphic from another server, that server is called 100 times to supply that graphic. If that graphic is 20K in size, those 100 hits cost the server that is storing it 2 Megabytes (20K * 100) in bandwidth.

Remote Loading in Email

ALL images and audio in HTML email are using remote loading, with the exception of "vidcaps" or "audio captures" (pictures or audio recording you've captured into that email using the WebTV Plus -- these files are actually attached to your email and travel along with it).

Does this mean that you are guilty of remote loading if you are using a GIF as a page background in your email, playing a MIDI, or are showing a picture in your sig? Yes, it does.

For example, if you are using a 20K graphic in your email sig, every time someone who can see HTML email opens an email that you've sent, that 20K graphic is called from the server where it is stored. If you send out 10 emails to your mailing list of 10 friends, that is 2 Megabytes of bandwidth from the server where the graphic is stored -- as much as 100 hits to a web page that has it. If you make just one post in a newsgroup and 100 people read it, that's another 2 Megabytes. And if they read that post again tomorrow, that's another 2 Megabytes -- the graphics are all called again.

Why Remote Loading is a Bad Idea

We've seen a good example this week of why remote-loading is a bad idea -- it can cause the website that is being loaded from to be shut down. GeoCities, Tripod, Angelfire, and most other hosts, prohibit remote loading from a website on their service. The reason is that it costs them bandwidth -- a lot of money -- but it does not give them the page views (and ad views) that pay their bills.

One of the curious things is that none of these hosts prohibit remote-loading to a site on their service. Their concern seems to be for their own bandwidth and pageviews, not for good Netiquette or eliminating the remote-loading problem in general.

But there are also some other reasons why remote loading is a bad idea:

Slow Loading and Broken Images

Web pages and email that are remote loading require every server that holds some of the files to be contacted and to respond with the files, before the page can be completed. This causes pages to load very slowly, and to display "broken images" if the files have been moved or deleted, or the web server doesn't answer.

And, when you remote load from another website, you have no control over whether or not those files you've called are going to be deleted or moved, or even if another graphic with the same name might be put in their place.

Webmasters who have a lot of remote linking to their images often rename their files on a regular basis. Whenever we move or rename some of our files, we often get an email saying "hey! you broke my sig (or web page)!" We try to explain that they are our files, and that the person should not have been remote loading them. Sometimes, they apologize... and sometimes, they just curse at us or remote-load another one of our files.

Unexpected Results

The picture or audio called by that filename also can be changed. For example, this month, we found that a WebTV user was remote-loading a picture of a WebTV Plus from Net4TV into his auction on eBay. We wrote to the user and asked him to stop. Not only did he ignore us and fail to reply, but he put up a second auction and also remote-loaded the same image. Several Megabytes of traffic per day was being pulled off of Net4TV by this user's auctions, and the graphic also was being used without our permission.

So, we simply renamed the image (changing our web page that referenced it to the new name), and put a new image in the directory with the name of the file that he was remote-linking. Instantly, the picture of the WebTV Plus disappeared from his auction, replaced by this:

Getting Caught

How, you might ask, did we know that this user was remote-loading our image onto eBay? Very simple -- we can see remote-loading in our server logs, and any website administrator who has access to the server logs can, too.

Every time a request for a file (HTML, graphic, audio, or any other) is made to a web server, it carries some information along with the request. One piece of information is the IP address of the computer that is requesting it (that's how we know how much of our traffic is WebTV users, for example, because we see the IP address of the WebTV proxy servers). Another piece of information is the "referring page."

If you have a regular hyperlink on your page to Net4TV and someone clicks on that link to come to our site, their request for the HTML page comes with the information that they were referred by your page. That's just fine, and we appreciate it.

But if you're remote-loading one of our images, we can see that, too. The server log shows the hit to the image, and gives us the referring page address -- yours. When we get concerned is when we see a lot of bandwidth going out from our graphics or audio files, and those are the ones that we follow back to the source and ask the person not to do that.

If you're remote-loading something into WebTV email, we can see that, too. We can't see the email address of the person who is doing it, but we can see the referring page as "WTV-MAIL".

This is how GeoCities was able to "sweep" and shut down a lot of websites for remote loading, without having to examine every one in detail. The server logs showed them the outgoing traffic that was not being referred by a webpage in the same GeoCities address.

How to Avoid Remote Loading

Use the Transloader, Freeloader, or the uploaders that are at Tripod and Angelfire (if you build there) to make sure that all of the resources that you are using in your web page -- the graphics and the audio -- are also in your website directory.

Once they are there, you can use "relative references" (just the filename, rather than the full address) to call them. This also makes it easy to mirror or move your site to another host. Once the calling page has a new address, all of the relative references will point to the new address, too.

Things You Might Overlook....

Award banners and graphics for webring control panels often are remote-loaded. If someone gives you an award or you join a webring, transload the graphics to your own directory, and then hyperlink (make a clickable link) back to the site that they come from.

If you hand out awards or run a webring, ask your recipients and members to transload the graphics to their own site, and follow up to make sure that they have. Otherwise, your site host may shut you down because of the "outbound" traffic from the hits your graphics are getting on another site.

Avoiding Remote Loading in Email

Don't use backgrounds or images from websites in your email, unless the person who owns the website gives you specific permission and is paying themselves for the website, or is on a web host that doesn't mind (if any exist).

Many of the sites that were suspended on GeoCities were not themselves involved in remote loading, but other people were remote-loading from them into WebTV email. Some of these site owners even thought it was OK, and gave people permission. But GeoCities, who pays the bills and makes the rules, didn't think it was OK. Don't cost your friend his or her site by remote-loading from it, even if you've got permission.

The ONE Place for Remote-Loading for WebTV Email

If you want to have HTML email that shows off some pictures, there is one place that it's OK to remote load them from -- your WebTV PageBuilder web page.

The remote-loading problems in WebTV email are caused by the HTML display of that email calling the remote servers. If you send me an HTML-filled email, I can't see the graphics -- my email reader doesn't show them -- so there's no remote loading when I open the mail. But when you send to a WebTV user, or post in a newsgroup, the graphics are remote-loaded when the mail or post is opened and displayed.

WebTV email to other WebTV users stays inside the WebTV service. So do the posts on WebTV's newsreader (and on their news servers). So, if you remote-load from your PageBuilder page on the WebTV servers, most of the bandwidth stays inside the WebTV service.

Right now, the WebTV PageBuilder does not support MIDI files. What this means, unfortunately, is that there is no way currently to include a song in your email without remote-loading from another site outside the WebTV service. Please don't do it -- complain to WebTV instead until they support MIDI in the PageBuilder.

IMPORTANT: WebTV's Customer Service department has told users that "to put MIDI in your email, you have to know HTML." In other words, they are telling you that you have to remote load it from another site. This is bad advice. Tell them that they are promoting theft if they tell you this, and that they must support MIDI in the PageBuilder.

The Cost of Bandwidth

The reason that this is such as sensitive issue is that Internet bandwidth is expensive! At Net4TV, our T1 costs us over $26,000 per year, and that is a relative "thin" line that can get full very quickly. Bigger sites have "fat pipes" connecting them directly to the Internet backbone, but they not only pay a very high price for these, they also pay in addition for the amount of bandwidth they actually use.

Free hosts like GeoCities and Tripod rely on advertising views to pay for the bandwidth, so that's why they don't want remote loading that takes the bandwidth but doesn't give them ad views in return.

Others, like the "free sites" that some ISPs will give you when you sign up with them, or sites that may charge $10 per month or so for hosting, usually have a monthly bandwidth allotment. A typical ISP may give you 500 MB a month in traffic with your "free site," or "$10 per month" site, and then charge from 3-cents to 10-cents per Megabyte for anything over that. I know of several artists who had to shut down their sites, when their ISP presented them with a bill for several hundred dollars worth of bandwidth -- all from people remote-loading graphics from their sites.

For More Information

We have a companion story, TOS Questions and Answers to help you see what you can and cannot do at the popular websites.

Nirvana has also contributed some advice in Staying Within the TOS at GeoCities.

You'll also find these resources by Beth Candy to be helpful, especially relating to your PageBuilder files.

Complete Uploading -- Step By Step

All I know About Uploading

All I know About Transloading

My Sig Storage


To Top of Page

Welcome to Net4TV Voice
Meet your fellow users who create
Net4TV Voice in the Masthead.

View our Privacy Policy.


Net4TV, Net4TV Voice, Chat4TV, and Surfari
are trademarks of Net4TV Corporation
© 1998 - 2001, Net4TV Corporation. All Rights Reserved.