- From: James Gwertzman <gwertzma@das.harvard.edu>
- Date: Wed, 12 Apr 1995 19:53:30 -0400
- Cc: www-talk@www10.w3.org
I have been researching caching on the Web for a while now, and have found that using both proxy caches as well as more sophisticated server-based replication methods, network bandwidth can be reduced by a factor of 60% or more. A draft of my thesis can be found at: http://das-www.harvard.edu/research/vino/push.cache/ or ftp://steward.harvard.edu/users/gwertzman/thesis.ps.gz for those who are interested. I am worried that the real-time audio system will be used for application that do not actually require real-time audio. There are advantages to downloading a file first; namely that it is a cacheable entitiy. A real-time audio stream by nature can not be cached. It may be argued that this is a security precaution, that music companies do not want their music to be easily copied, but it seems that it should be trivial to re-record an audio stream as it is being received and save it to a file. It could be argued that network bandwidth is always growing, but it seems foolish to knowingly waste it. There are several ways that the Web community is already wasting bandwidth: html pages could easily be compressed, for example, as part of the protocol, and uncompressed as they are received. Likewise I am looking forward to certain dynamic pages being made available as scripts that can be cached and replicated. It is cheaper for a script to reference a piece of shared data at the primary host than it is for the browser to retransmit the entire page again with the updated information in place. if someone knows more about the realtime standard I welcome their comments; Maybe I'm wrong and it would be possible to cache these pages. Certainly the original audio file could be replicated using the techniques I have developed in my work, although proxy caching would still be difficult. James Gwertzman. gwertzma@das.harvard.edu
Received on Wednesday, 12 April 1995 19:53:45 UTC