Am 2008-02-13 10:25:32, schrieb Matus UHLAR - fantomas:
> by using the same URI? or by different URI each time a song is requested?
> each of this makes problems with HTTP caching...
Yes, it is always the same url...
For example: The original file is sampled in 192kBit and then a user
use:
<http://musicserver/?rate=64&name=how_to_get_gnump3d_caching.mp3>
which would resample the file to 64 kBit, but requesting the same file
10 times, result in 10 different files...
The resamlpling is NEVER the same... (checked with md5sum)
I the only thing I can imagine is, that I write a gnump3d patch, which
copies the resampled file into a cache directory, which can be in a
ramdisk, and then the next time someone is requesting the same URL,
gnump3d is looking first into the cache and if it is there, it use it
and otherwise it resample the file.
> 4 users listening to 160 kbit/s songs in parallel will make ... 640 kbit/s
> traffic. most of disks can handle that :) Of course if squid is configured
> to fetch more data than user requests (see quick_abort settings) and users
> tend to switch songs fast, it may make problems.
Exactly...
Thanks, Greetings and nice Day
Michelle Konzack
Systemadministrator
Tamay Dogan Network
Debian GNU/Linux Consultant
--
Linux-User #280138 with the Linux Counter, http://counter.li.org/
##################### Debian GNU/Linux Consultant #####################
Michelle Konzack Apt. 917 ICQ #328449886
+49/177/9351947 50, rue de Soultz MSN LinuxMichi
+33/6/61925193 67100 Strasbourg/France IRC #Debian (irc.icq.com)
<<attachment: signature.pgp>>
