> It may be meaningless to most listeners, but having it tracked (and > public-domain) is valuable to admins and marketing types alike, if your > goals lean that way.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.>Froma marketing angle, you might even argue the other way, that peopledon't want this information published (except to advertisers).> >type > > type of the stream > > ex.: audio/mpeg or application/ogg > > I find this pretty irrelevant myself, especially from a user > perspective.It's not for the users.> It can (and should) be indicated on the specified URL,Go read a basic document on Internet Standards. Encoding meta information (especially type) in a filename or URL is broken and wrong.> you'll pardon me for saying, seems to violate the "spirit" of your > reasoning behind wanting to remove listener counts. I think the only > people that would give a damn about this are people who endorse a certain > technology over another (Mpeg vs. ogg vs. wma vs. whatever).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. 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.> >ttl > > time to live. number of minutes an entry is valid for. subsequent > > directory changes will refresh this value. when the value > > reaches 0, this entry will be removed. > > ex.: 5 > > I don't think this should really have anything to do with the directory > itself. It should be a transparent server-side configuration > parameter. If clients can set it then you just end up with clients that > connect once with 9999 (or whatever your max value is) and then never > connect again to spam the server.. fill the directory up with all kinds of > garbage.We want clients to be able to set it, and if it's documented, they will likely set it responsibly. You don't want someones commercial stream that is on expensive bandwidth and never goes down to hit the server as much as everyone else. This will help scaling a bit I think, as people who are knowledgeable about how things work can change the default values to be more efficient. 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.> > >auth > > authorization string. this is a md5sum of of some > > random data. > > ex.: echo 'jack@xiph.org|Jack Moffitt|password' | md5sum > > What is the purpose for this? Is one of the other mentioned fields going > to be dependant upon this being correct?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.> yp, but really in icecast as well) a more robust template facility, like > shoutcast has.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.> It's very easy for me to give my mirror maintainers a > template file that they can use to generate their stats for inclusion into > my mirror list if they're using shoutcast; using iceast is a hassle > involving either modifying the current templates and screwing up god knows > what, or writing scripts to hit one of the current status pages and then > post-processing the output before including it on the webpage.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 :) 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@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.
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@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.
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@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.