[icecast] a new directory service
all at biosys.net
Mon Sep 17 21:53:53 UTC 2001
At 09:10 AM 9/17/2001 -0600, you wrote:
>That's what logs are for. This is not a public log. Things are not
>tracked over time. The information is only valid for a 'ttl' period.
I'm just going to let this topic about listener counts lie.. I think enough
people besides myself have stepped up in favor of it, and you have your
reasons for not wanting to have it. It's up to you to decide (If you do
decide to go ahead with this project) what outweighs what.
>Go read a basic document on Internet Standards. Encoding meta
>information (especially type) in a filename or URL is broken and wrong.
I wasn't suggesting it be encoded in the URL.. only that if you go to the
URL (not the client-listen url, the website url) there should state what
type of streams they provide. I think most people already do this, or if
not, they have at least a short list of clients that are known to be able
to tune in.
>Or people who value freedom and want to use only Free technology. This
>serves a few purposes though. a) a directory admin could lock this
>field to a single value, doing service for only Vorbis for example. b)
>supporing legacy and discontinue or nonupgradeable products that are MP3
>only will need to know.
Locking the field is fine.. but I think this goes back to separating the
front-end from the back-end. Listing it in the directory listings is just
silly IMHO. It's even sillier if the admin only wants to support
technology X, as it would just be the same redundant information repeated
over and over for every station, wasting screen real estate and bandwidth both.
>And of course, if you think that people don't care about quality at
>lower bitrates, then I disagree with you. I would chose a Vorbis stream
>over a MP3 stream any day, if the rest of their attribute were similar.
As would I. I'm not a supporter of the MP3 format for any reason other
than the current installed base of software uses it and uses it, and it's
reliable. I see two things that need to happen to make this a reality.
1. Icecast needs better metadata support, and hopefully the template idea
we return to in a bit.
2. Winamp needs Ogg support by default, or at least via a reliable plugin;
both in decoding and encoding.
I still occasionally have problems with the metadata streaming on Icecast
if I leave the stream up for a log period of time, and Winamp is by far the
client that is most widely used to listen to the stream. I also prefer
Winamp for my source, because all of my workstation boxes are Windows
based.. that won't be changing any time soon.
>This also brings up another reason to ditch listener counts, and that is
>that it's TIME DEPENDENT. All of these other values are not time
>dependent. They will be valid the entire ttl, or until the server goes
I'm just getting more and more confused as I try to reply to this. I've
written and erased three different paragraphs so far. Let me try and
collect my thoughts here...
I think that at-best this TTL field should be more accurately named MAXTTL
unless you intend to disallow updates to the directory while the TTL is
Also, there are other time dependant pieces of information you seem to be
overlooking here such as Stream Title (mine changes depending on the name
of the current show), Track Title (obviously changes frequently, and at
strange intervals) and others.
What you're basically doing here in any respect is building a DoS into the
software on purpose. If you've never used something like Gnutella then it
may not be so obvious, but I guarantee it'll only be a matter of time
before software pops up that spams the server with multiple "streams"
showing music in every conceivable genre so as to get their stream listed
no matter what preferences the listener decides to sort the listing with.
This should without a doubt be an admin tunable knob, not something to be
set by clients. If you intend this directory lister to achieve widespread
use, especially as the software-of-choice for running public directory
servers, this must absolutely not be tuneable by the client.
>This string is set buy the listing client. The server will contact the
>server for that URL and a compare process will happen. If the entries
>match, It will get listed. Clients do not have access to this value,
>except listing clients which set it. Once you're in the directory,
>updates must contain this value too. This prevents people from forging
>your information, or hijacking your entry.
Applied Cryptography begs to differ with you.
Sending a hash across the network is no more secure than sending a
cleartext password, if all that is required to authenticate is the
hash. What you really need is something like Diffie-Hellman to do the
negotiation, or a public-key system.
>We had templating a good long while before shoutcast did. And people
>did some crazy things with it. Hardly anyone ever used it, and it fell
>into disrepair. I'll keep this in mind for icecast 2, which already
>outputs XML documents.
>You won't need this for icecast if that's your use. You can use request
>and parse the stats.xml which will dump all stats on the server. You
>can also connect as a stats client, which will give you a dump, and then
>realtime stats updates while you stay connected. And that _already_
The request-and-parse approach is horribly inefficient. It requires me to
set up some kind of cron job or server side scripting to do this step and
then convert the output to the format I wish to display on the main site
for the stream. This causes linearly increasing load on a single machine
instead of distributing that load among all the mirrors.
I realize I can do the things you've listed, and have done them in the
past.. but it's just horribly time consuming and process consuming compared
to simply using SSI in Apache to request a URL from the remote stream and
having a template that is one row in a table.
Hmm I think the missing point here is that I'm primarily an Admin for my
*nix machines, my C/C++ is very neglected and rusty. I'd rather not have
to code things myself that will take weeks for me to get right when the
author of a particular program could have included that functionality
almost without a second thought.
--- >8 ----
List archives: http://www.xiph.org/archives/
icecast project homepage: http://www.icecast.org/
To unsubscribe from this list, send a message to 'icecast-request at xiph.org'
containing only the word 'unsubscribe' in the body. No subject is needed.
Unsubscribe messages sent to the list will be ignored/filtered.
More information about the Icecast