[icecast] a new directory service

[Jack Moffitt]

I apologize for the delay in response time :)

I got busy.  Now I'm back :)

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

Yes your right.  I also want to get people into going to these sites.
There's _real_ information there.  The directory is a directory, and it
will never be a substitute for the broadcasters webpages.

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

Ah, in general I'm not dicussing here what's shown on screen.  Only how
the information is stored and used.  Once we lock this down, I imagine
we'll ahve 101 good ideas about how to present this information in a
good way.  That's the hard part :)

> 1.  Icecast needs better metadata support, and hopefully the template idea 
> we return to in a bit.

Icecast 2 has it.  Ogg has much better metadata than mp3.  Icecast
passes that on just fine.  it will also pull it out of the stream and
use it however you want.  This is the plan.

There will also be another ogg substream for metadata only.  This will
allow you to do all kinds of wacky stuff.  It's not done yet though.  In
the meantime you'll have much better metadata support than shoutcast to
tide you over.

> 2.  Winamp needs Ogg support by default, or at least via a reliable plugin; 
> both in decoding and encoding.

I'm not sure why this didn't make it into 2.77.  But I've been told it's
expected for 2.78.  They have to get it approved or something.  It'll be
there.

The current plugin is quite reliable now.  After lots of testing on
people's test icecast2 streams I think Peter has nailed most of the
bugs.  Also, the Windows Media Player plugins support streaming as well.
And if I ever finish the RealPlayer one, it will too.

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

Icecast 1.x metadata is crap.  I know it's crap.  You guys know it's
crap.  It isn't crap in 2.x. :)

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

Intent is the same, but your suggestion is certainly clearer.

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

The only title in the directory is the title of the station.  This is a
constant.  Show titles and song titles are transmitted in the comment
headers for vorbis streams or in mp3-metadata.

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

It's easy enough to stop this kind of attack, even automatically.  Note
that having every server send updates every 2 seconds is also going to
be a problem.  I'm trying to find some reasonable compromise.  We can't
100% stop cheating.  But I can certainly make cheating 'different'.
Taking away the listener count removes a strong temptation to cheat.
The idea is that if the temptation is weakened, cheating will not be as
big of a problem.

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

I'm not sure what you mean.  If you mean MAXTTL, it's certainly
reasonable that this be tunable by the client within some acceptable
range.  My current thoughts were 5 minutes to 1 day.  That way sites
that are very stable, can be nice about the amount udpates they do.
especially since there's no time dependent data, this makes things more
efficient.

Certainly someone can abuse things and set the thing to 1 day and then
take down there stream.  But there are programmatic ways to check on
people in the interest of keeping the directory content valid.

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

This is not to protect against sniffing.  This is to protect against
spoofing and stealing.  It is certainly adequate to do that.  It would
be unreasonable to bruteforce the 'password'.  

When I 'check' the password on the other server, I certainly won't be
transmitting it :)  There will be some challenge response type action
going on.

We don't need absolute security.  We need security to protect against
specific attacks.  If you'd like me to outline these in detail, I can in
a separate email.  I have notes on the attacks and how these methods
prevent them and also on which attacks are still possible.

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

The answer to this may be XSLT.  It is probably easy enough for me to
put XSLT capability into icecast.  This would allow you to specfy a
template to transform stats.xml (or some other xml).  That would give
you the output you want.

The downside here is that icecast is processing something.  As more
clients want to view this template icecast will do more processing.
Request and parse, while more inefficient for a few clients, is way more
efficient for many clients.  In a large scale environment you wouldn't
use either of these methods.  You'd write a stats client that listens on
teh stats port and gets hte updates in realtime (note that this
_already_ works now).  Then you can do processing without involving
icecast, and without request/parse/output overhead.

In the end, it's likely we will support all three models.  There's
nothing difficult about any of them.  I hadn't thought about the XSLT
stuff, but that is an elegant way to do it.

jack.

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