View Single Post
Old 22nd November 2011, 14:23   #13
Junior Member
Join Date: Feb 2004
Posts: 2
This thread has me interested in exactly how YP2/sc_serv2 actually work in comparison to v1 with regard to end-to-end reliability of a stream broadcast using v2 of the platform.

Originally Posted by DrO View Post
when the DNAS is working in YP2 mode, if the details from the authhash cannot be obtained from the YP then it will prevent clients since the stationname, etc passed to the clients is taken from the authhash details (unlike the v1 system which just uses what the source provides - in yp1 mode then that will still happen). as such clients aren't allowed since the DNAS is then in an illegal state. it probably seems counterintuitive but that's how it's been setup and will remain as things stand.
Originally Posted by DrO View Post
though as the yp2 mode works with the stored authhash details then i'd hope it makes sense why if the details cannot be obtained that the DNAS probably shouldn't be running as no details &/or no YP connection when set to be public is an invalid setup. at least it won't drop listeners if the YP connection goes away whilst the DNAS is running unlike the v1 DNAS can do.
I would like more clarification on the implications of this setup.

Does this imply that if the YP2 directory connection cannot be made in the middle of an ongoing streaming session, then all clients who might try to connect after the YP2 link goes down will be denied while the connected listeners still remain engaged with the DNAS as if nothing happened?

Does this also imply that the YP2 is queried upon every client login and forwards the stream details at this time, furthermore implying that such stream information is not cached within sc_serv2 during its runtime?

Originally Posted by DrO View Post
if it did go down then switching the DNAS to run in private mode would be the simplest way around it (though at the moment the v2 DNAS doesn't allow for changing that on the fly in all cases). then again, the service going away would affect v1 stations in a similar manner, so i think you might be over considering things (though can see why).
You sound confused with regard to V1. Exactly how would losing the YP be the same for a V1 vs a V2 DNAS when the V2 DNAS is intrinsically different?

With V1, all I can figure is that there would be no public YP directory listing for the stream.

This lack of YP services does not preclude a stored URL in a playlist, nor a direct link from a website. V2 denies client connections if the back-end link to the YP is severed.

V1 streams remain connectible regardless of YP interaction.

Clients provided with direct links or with stored playlists always have the URL to the stream, and should at any moment be able to connect as they already know where the stream is. There is -no- requirement that clients visit the YP to access the stream in any case, thus there should be no denial for clients with a direct link in ANY situation. Why does V2 have this as a designed-in bug?

Is Nullsoft able to guarantee they will never go down, thus wrongfully denying radio listeners their stream due to a bad design of the DNAS? If the stream was working, and your ISP's core router fails at an inopportune moment, why should I have to change my configuration to fix your problem?

Please explain this. I am very curious. Seriously.

With the amount of potential for your failure to become my failure, why exactly would use such risky software? The only answer possible: Your market share locks customers in. There is no alternative directory that is in the mind of the masses. Your trademark has become a noun. You are the Kleenex of streaming media.

Due to this, why not make the software guaranteed reliable so as to not potentially damage the reputation of stations who wish to be publicised?
mystica555 is offline   Reply With Quote