[icecast] a new directory service

[Asymmetric]

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
>away.

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 
still non-zero.

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_
>works :)

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.