Matus UHLAR - fantomas wrote:
If they're all listing to different remote sources at different times
then there's no point in caching it...
But if I read the logs, they are around 150-180 files which are heared
all the time and they have in summary arround 800 MByte. So creating a
Ram-Cache of 1 GByte would do wonder...
I still have no idea what URIs are requested by users when they are
listening to those songs. In such case I can't do anything but guess...
try:
http://streaming.uoregon.edu:8000/
If they are live streams (internet radio) the the fact that the filename
is the same every time isn't going to make it cacheable... The file is
just the mountpoint for the the stream... Every user joining the stream
will start at a different temporal location so you cannot just serve
what you already cached, rather you have to serve what's currently being
streamed. if you have multiple clients listening to the same stream then
they're going to need approximately the same data at the same time,
varying buffer depths and the fact that tcp is being used
nothwithstanding, that's why a i suggested a relay if you have
particularly popular content that you wish to neck down to one stream.
eons ago this is probably something that would have been solved with ip
multicast (which you might call a degenerate form of network caching)
but interdomain multicast deployment never really achieved critical mass.
It is plausible I suppose to implment internet radio support in squid
which would recognize two client connected to the same url, and
replicate the incoming payload from one to the other. That wouldn't
require any disk i/o at all.
