View Single Post
Old 22nd November 2011, 16:46   #14
DrO
 
Join Date: Sep 2003
Posts: 27,873
Quote:
Originally Posted by mystica555 View Post
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?
when using the v2 DNAS in YP2 mode, if the YP connection fails i.e. no touches then it will not prevent client connections. my comment is that the v1 DNAS under such situations can and does drop client connections - the v2 DNAS does not.

Quote:
Originally Posted by mystica555 View Post
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?
it's obtained when the v2 DNAS does it's add for the stream, otherwise as long as the source does not disconnect then the details obtained from the add will be used. i'm not sure how you got the idea that it's querying the YP for every client connection.

Quote:
Originally Posted by mystica555 View Post
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.
Quote:
Originally Posted by mystica555 View Post
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.
no, as already covered it only prevents client connections if the add is not able to be made. as long as the add happens and things then fail after that then it won't affect things. however, see my last paragraph in this reply for a followup on this.

Quote:
Originally Posted by mystica555 View Post
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 Shoutcast.com 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?
there is no requirement that clients visit the site with the v2 DNAS either. if you're telling it to be listed in the YP then it's only fair that the DNAS favours that handling. why this was done i don't know (before my time working on the tools) but it seems fair how it works. and other people have raised the issue but if it's that much of a concern, you either revert it to work in YP1 mode or stick with your unsupported v1 DNAS.

Quote:
Originally Posted by mystica555 View Post
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?
no one can guarantee 100% uptime (and if they do then they are lying). as you seem to have mis-interpreted some of what i was trying to say, i think the above reaction is possibly going ott.

Quote:
Originally Posted by mystica555 View Post
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.
if you don't like the terms of using the tools then you don't have to use them. the choice is there. all i'm doing is working within the design which has been put in place before i started working on the tools and i can see that this will put some people off, but i can also see the benefits of using the authhash system (protects station details especially against rogue DJ's screwing with things, makes clustering easier by just ensuring the same authhash is used, has more aspects coming).

Quote:
Originally Posted by mystica555 View Post
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?
as already mentioned, no one can guarantee things to be 100% reliable be it software, networking, etc though it is strived to be achieved.


i'm not going to cover it as a bug, however more as a feature request since it is a fair point that if the YP cannot be accessed only if it fails to resolve / respond on add and not a failure to provide the information (that behaviour will not change), then yes it probably should drop the requirement to block client connections due to a lack of authhash details. however we then get into the weird area as to what to do to clients which have then be provided with different details from what would be in the authhash when the YP connection then comes back... kick all so they then get the correct details or just leave them going and only apply the new details to new connections.

so does that seem fair / alleviate the core issues you're having with how things currently are designed and work as planned?

-daz
DrO is offline   Reply With Quote