A socket policy server...

[Smelter]

Nice!

[DrO]

Originally Posted by thinktink

Sail a Windows and Linux version over this way yonder.

sent email with win32 and linux86 builds which also has the shoutcast.swf self-hosting working. have confirmed it working with jaromanda's player though thundersnow doesn't like how i'm running it as it tries to hit the root domain to get the files which i'm not able to ensure with my web-side testing at the moment.

-daz

[thinktink]

Om Nom Nom...

Testing shortly...

[thinktink]

Need to support HEAD for swf resource.

While testing under Windows:

No port 843 policy server enabled during this test.

In the reply header I think you need a space between:

code:
Content-Type:<Need a space here>text/application/ x-shockwave-flash

Content-Length:<and here>?????

You've got the type of the SWF resource as "text/application/ x-shockwave-flash" when it should be "application/x-shockwave-flash" in the header.

You should make note in the documentation that you still need to supply a crossdomain policy file in the DNAS configuration if you don't configure the DNAS to service crossdomain on port 843 (or whatever port you set it to.)

Otherwise this seemed to work fine for PTS. I ran a webserver to serve the page that referances the swf on the DNAS (full URL and port to it) and made the playlist.xml file scriptable so that it would present the host to connect dynamically (to wherever it was connected to (the Host field in the request header.))

If you know what you're doing it's not very difficult to get it working with full metadata support with PTS.

Port 843 policy serving also works as expected. Only issue is that you need to give the ability to change the port number for custom swf players, just like in the Transcoder.





Will test Linux version next. Wanted to get this all down before I forgot.








While testing under Windows I noticed that in my Application Log sc_serv was reporting that "faviconmimetype=image/x-icon" is an invalid config option. Looks like it's been doing that for a while so it's not specific to this test build.

[Smelter]

if you need any thing in the swf department from me, just holler.

[thinktink]

Took longer than I thought to install the Adobe Flash Player into Firefox on Ubuntu. That was annoying.

Anyways, linux testing is complete. Same suggestions as my previous post, header, type, ports, spacing, and whatnot. Otherwise PTS seems to work just fine on Linux as well. Tested with Apache2 w/php on Oracle VMbox Ubuntu 10.04 LTS.

[DrO]

Originally Posted by thinktink

In the reply header I think you need a space between:

code:
Content-Type:<Need a space here>text/application/ x-shockwave-flash

Content-Length:<and here>?????

it shouldn't need a space to work and most of the DNAS doesn't output a space in those values as whitespace should be ignored with such things (from my understanding of how header values are meant to be processed).

Originally Posted by thinktink

You've got the type of the SWF resource as "text/application/ x-shockwave-flash" when it should be "application/x-shockwave-flash" in the header.

fixed, that was late night just before sleep coding at it's best, heh. fixed.

Originally Posted by thinktink

You should make note in the documentation that you still need to supply a crossdomain policy file in the DNAS configuration if you don't configure the DNAS to service crossdomain on port 843 (or whatever port you set it to.)

the preliminary doc edits i've made put the new config option in the same section as the one for the file specification, though will be making it provide the default contents of the crossdomain.xml file if one cannot be found just to ensure it's not going to fail too badly (like is done with the robots.txt file support).

Originally Posted by thinktink

Port 843 policy serving also works as expected. Only issue is that you need to give the ability to change the port number for custom swf players, just like in the Transcoder.

i had initially done it that way but then from my tests and reading around, it seems like port 843 is only used anyway. i can add it back in but was trying to keep things simple (and was thinking of changing sc_trans to just toggle 843 on/off).

Originally Posted by thinktink

While testing under Windows I noticed that in my Application Log sc_serv was reporting that "faviconmimetype=image/x-icon" is an invalid config option. Looks like it's been doing that for a while so it's not specific to this test build.

have fixed that as there was a typo in the internal name of the config option.


so bar the few little quirks, i just want to make sure if we can call this a success?

-daz

[DrO]

Originally Posted by DrO

the preliminary doc edits i've made put the new config option in the same section as the one for the file specification, though will be making it provide the default contents of the crossdomain.xml file if one cannot be found just to ensure it's not going to fail too badly (like is done with the robots.txt file support).

just had a thought about this and am thinking of changing things so that by default a crossdomain.xml will not be present in the root of the sc_serv install folder and will instead provide what has been in the default file in-dnas but have it output the following:

<allow-access-from domain="*" to-ports="portbase,portbase+1"/>

or

<allow-access-from domain="*" to-ports="portbase,portlegacy"/>

or

<allow-access-from domain="*" to-ports="portbase"/>

i.e. all 3 public port configurations allowed, as it's probably better to only allow access to the ports related to the DNAS than a blanket access.

-daz

[thinktink]

Originally Posted by DrO

so bar the few little quirks, i just want to make sure if we can call this a success?

Yes.

Originally Posted by DrO

just had a thought about this and am thinking of changing things so that by default a crossdomain.xml will not be present in the root of the sc_serv install folder and will instead provide what has been in the default file in-dnas but have it output the following:

Sounds about right (a security wonk would probably tell you option 3.) However if a crossdomain file is present then I think it should override the default behavior (I think that's what you meant to imply, just double checking.)

[DrO]

Originally Posted by thinktink

Sounds about right (a security wonk would probably tell you option 3.) However if a crossdomain file is present then I think it should override the default behavior (I think that's what you meant to imply, just double checking.)

yup, if a custom file is specified / present then that will be used instead of the in-built option. have also added an option on the server admin summary page which will allow for clearing the cached instance of that file so it can be updated whilst the DNAS is running (otherwise it required the DNAS to be restarted or would keep re-loading the file from disk everytime).

have sent a link to a newer windows test build for some of the points raised.

-daz

[thinktink]

Windows and Linux all working. All quirks you addressed appear resolved in all versions provided.

[thinktink]

lol, gawdamn, now it's like you have to be TRYING to get it to fail. lol

[DrO]

cool, thanks for the confirmation. can scrub that off the todo list now

-daz

[thinktink]

lol, now I guess pretty soon the only thing my SPS is going to be good for are legacy broadcasters. lol, That's still good though.

[DrO]

unless i do things right so that no one stays on the legacy dnas... i can only dream, heh.

-daz

[thinktink]

Originally Posted by DrO

unless i do things right so that no one stays on the legacy dnas... i can only dream, heh.

-daz

lol

[thinktink]

I wonder how long THIS link will last.
http://www.mediafire.com/?4odmoduj1ntsfon

Providing another link again until the new v2 DNAS comes out.

[Smelter]

thunder now moved to svn

http://code.google.com/p/project-thunder-snow/

[thinktink]

Maybe this one will stick longer than 5 days :
https://dl.dropbox.com/u/88236802/Bo...SInstall1_0.7z