Re: Save 15% on your bandwidth...

>
> You've got a good point...
>
> But what it seems the person had said was that he placed copies of the
> files/programs to be ftp'ed locally from his machine. If that's the case,
> it's different than simply caching it; it's almost like creating an
> unauthorized mirror.
>
> I guess it's up to interpretation; if it's a result of caching I guess
> we'd have no control of it, but I wouldn't store these files locally (not
> as cached).
>
> On Thu, 12 Sep 1996, Jonathan Larmour wrote:
>
> > At 15:11 12/09/96 -0700, Ricardo Kleemann wrote:
> > >
> > >You just better hope that Netscape & microsoft don't find out about
> > >this... ;-)
> > >
> > >It is NOT legal to store their files/programs and then make them
> > >available to others, don't forget that...
> >
> > So e.g. a Netscape proxy cache shouldn't be allowed to cache downloaded
> > versions of Netscape then? Bizarre. Are you sure about that?
Once usoft, mcom or everyone else placed something on a public ftp/web site,
they have very minimal control over further life of those files.
Usually I got downloaded stuff on floppies, (write once) CD-ROMS, IDE disks etc.
In this concrete case, while users reference those files by URL's pointing to more or less
official sites, then we do caching. If users refer to our server, then we made an unofficial mirror.
That makes the difference.

But I wanted to tell about another (sligthly more important in technological sense)
aspect of such use of redirectors:

When Duane announced the redirector feature first time, I maked a virtual note for
myself to implement some kinda URN resolver on top of it.

Technically Richard assumed that in some situations the filename component (sans path)
may serve as an URN. Implemented the URN resolver by individual collection of
appropriate files and with some C code.
I got:
!Forbidden
!
!You don't have permission to access /local/rredir on this server.
when attempted to access the directory found in the C source.
The implementation is correct in doing that.

What I want to see is some more automated machinery. (Once in the past I partially implemented a similar
stuff on top of ftpmail. I named it as virtual ftp mirror.)

The basic idea was: finding ftp pathames having 2-3 common components is a sign of an existing mirror,
I checked how full is the new mirror found, then compared transfer rates and used the fastest.
Of course I feed in into this stuff all mirrors announced on the original ftp sites. Many of them
were not real mirrors. :-(

Sometime in the future I will surely search the whole cache for identical files and make note of their prefixes
in a dbm database. Later will compare all files having those prefixes looking the same (directory comparison).
For FTP urls even will get directory listings.
BTW. Richard, you didn't get false hits yet? *win*.{zip,exe,arc..} etc patterns in 8.3 name space may produce them!

Apropos, "URN"s like /rfc/rfc\d+.txt and /internet-drafts/draft-*.txt will not save some bandwidth/disk space?
(but surely not 15%, technical surfers are rare compared to PC users.)

Andrew. (Endre Balint Nagy) <bne@CareNet.hu>
Received on Thu Sep 12 1996 - 18:22:42 MDT