[icecast] a new directory service

[Jack Moffitt]

> if "YP responsible for time-dependent data" is the method, then there is no 
> requests sent to the actual streams, and you only incur the 10 requests to 
> the YP.

But we're also managing time-dependent data.  Which means _everyone_
will need to update constantly.  So there's much more load from the
streaming servers.

Also, since the yp directory handles the time-dependent data, if you
want to find out what's playing on your favorite stations, you incur
load on the yp infrastructure as opposed to just asking those few
servers.

There is certainly traffic both ways.  Sure it's nice to cache all that
data for lots of clients, but it's also not as accurate, nor as
flexible.

> So, from a streamer's point of view, I now have to calculate bandwidth 
> required for my stream + bandwidth required for a possibly indeterminate 
> number of client requests.

Bah.  This has not been a problem in all the years that quake has worked
this way.  The amount of data in these requests vs. the actual stream
data is negligible.  It's doubtful you'll even notice.

>   Also, I don't see this scaling very well from a 
> streamer's point of view...if I am running on a modem connection then how 
> many YP browsers will it take to occupy all the available bandwidth 
> answering the "What's Playing" request ?

Considering you could only have _one_ listener, this is a pointless
example.  No one is going to be streaming from a modem.  And if they
are, they aren't going to be advertising themselves on YP.

> ok, so a logical counter-points would be :
> ***make the model such that YP browsers only request this info for streams 
> that they are interested in.  That would reduce the amount of "What's 
> Playing" information that is redundant and not really used.***
> I would consider this a very tough thing to do effectively. 
...
>  Obviously you 
> can't just have a YP client that makes you click on a station and tell it 
> to "refresh song titles"...That's just not the way people leaf through the 
> YP info (my opinion).  People want to search for "The Rolling Stones" and 
> come up with a list of stations that are currently playing the 
> Stones...This kind of request would be almost impossible in the "server 
> responsible for time-dependent data" model.

There are a few ways to control this.  Some are pretty easy.

Your suggestion of only request info for a subset of streams is quite
easy.  You suggest for each stream to refresh, but that's isn't very
nice.  You could easy limit filter the streams and update only those.
This is what Quake servers do.  There's no point updating all of them
everytime, when you're only going to be interested in a few of them.

You assumption that people will want to search all streams for a keyword
is also somewhat flawed.  If the yp server is caching the data, this
search is mostly pointless.  If you found the stream that was playing
the rolling stones, it's as likely to be at the end of the song or past the
song than at the beginning :)  However, this kind of search would be
quite easy on a subset when the data was coming right from teh servers.

So there are other ways too.

One way is to limit the speed of the update on the client side.  And
also make it unordered (so that two clients will make requests in
different orders).

The other solution is to limit it on the server side.  Certainly there
should be an option that says "I do not answer requests" for those
servers who don't have useful time-dependent data or dont' wish to share
it.  I think this is a quite effective solution, especially if the
server admins can configure it.

> if you want to find out what browsing through a time-dependent-less 
> directory is like, force yourself to use the Live365 directory (no song 
> titles, no listener counts)...they have no time-dependent information, and 
> if you want to know what's playing, you can find out (making a client 
> request) by clicking on the stream....This is a wholly useless directory in 
> my opinion...

Their directory is bad for many reasons.  Besides, nothing says that we
can't also try and cache the time-dependent data somehow too.  I just
don't think it should be done in the same way.

Also, I'm not trying to build the be all end all directory website here.
I'm trying to build a generic infrastructure for this.  I hope to
facilitate _many_ interfaces, and _many_ separate directories (LDAP
supports heirarchies).  It's possible these issues wont' be big issues
in that kind of structure.

And if dir.oddsock.com caches the timedependent data and _looks_ like
current directories, why does the users care what the architecture is
like?

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.