On 12/04/2008, Michael <[EMAIL PROTECTED]> wrote: > > On Saturday 12 April 2008 05:57:49 Brian Butterworth wrote: > > If it were all doing using HTTP it would be easily cached, of course, as > > you can do this with a proxy server, either a configured-in one as used > on > > corporate and educational networks, or as a transparent proxy. > > Ignores the fact that most caches will not cache objects over a certain > size. > (The maximum usually based on average object size, which is dominated by > small images and HTML). Also it depends on the purpose the cache is there > for - speed or bandwidth savings, and even then you still need a maximum, > it's > just where you set it which will vary.
Every proxy server I have set-up allows you to configure this! There is no reason whatsoever that large files cannot be cached, and even part-retrieved. If this is really a problem, then you could set up a server for each ISP with the files copied on their network with the Iplayer software being redirected to the fastest file when available. So, if you watch a programme on a BT (Phorm! boo, hiss) ISP line, you get the stream from iplayer.btinternet.com, on talktalk from iplayer.talktalk.com etc. If we are talking of saving the ISPs the billions of pounds they claim it cannot be beyond the wit of us programmes can it? There are algorithms that will take into account object size and popularity > (combination of LFU & GDS approaches), but they're still mainly targetted > at > object size distributions below the 90-95th percentile. > > You can use whitelisting, but the maintainence overhead of such a > whitelist > can become quite spectacular, and can depend on the purpose behind > caching in their network ((peceived) speed saving or bandwidth saving[1]). > Thus, whitelisting or changing the maximum object size can massively > impacts the effectiveness of the cache infrastructure as a whole. > > [1] These two do not always correlate, since one is based on > percentiles, > the other is absolute figures. > > (I worked for the best part 5 years looking at this sort of stuff in great > detail in both theoretical and (a wide variety of) operational > environments, > so I'm summarising :-) > > Also, none of this is any use for streaming over RTMP. (and HTTP streaming > has major issues, not least the fact that you can't index sensibly by time > without impacting (or working around) patents) > > NB. I'm all in favour of making websites cacheable where > possible/reasonable > since it's a really, really, good idea, but it's just worth remembering > we're > looking at outlying values regarding a non-HTTP protocol. > > > Michael. > - > Sent via the backstage.bbc.co.uk discussion group. To unsubscribe, please > visit http://backstage.bbc.co.uk/archives/2005/01/mailing_list.html. > Unofficial > list archive: http://www.mail-archive.com/backstage@lists.bbc.co.uk/ > -- Please email me back if you need any more help. Brian Butterworth http://www.ukfree.tv
