koobas.hobune.stream
SocketPolicyClient error w/ Mac Webplayer
I'm getting the following error with the mac webplayer running in Safari. It outputs the same error message over and over again (this is in Player.log), each time incrementing the number after SocketPolicyClient by 1. Eventually it'll get into the thousands:
SocketPolicyClient1: Incoming GetPolicyStreamForIP
SocketPolicyClient1: About to BeginConnect to 127.0.0.1:843
SocketPolicyClient1: About to WaitOne
SocketPolicyClient1: Caught exception: Connection refused
Unable to connect, as no valid crossdomain policy was found
null packet
SocketPolicyClient2: Incoming GetPolicyStreamForIP
SocketPolicyClient2: About to BeginConnect to 127.0.0.1:843
SocketPolicyClient2: About to WaitOne
SocketPolicyClient2: Caught exception: Connection refused
Unable to connect, as no valid crossdomain policy was found
null packet
According to the docs, port 843 is where the webplayer tries to fetch crossdomain.xml, so obviously it's stuck in some kind of infinite loop looking for the security policy for localhost. As far as I know we're not doing any weird proxying on the local machine, and no other process appears to be using that port.
Timing wise, it does this right after making a call to our search core:
Search http://neis.fragileearthstudios.com:8080/neiscoreSolr/rest/search?q=*&start=0&rows=23&wt=json&facet=true&facet.field=tags&facet.field=server&facet.field=period&facet.field=status begun at 2013-03-25 14:39:02.536
However, that site has a valid crossdomain: http://neis.fragileearthstudios.com/crossdomain.xml . It's entirely possible that the search bit is just coincidence - about 2 dozen different things are going on at that time as the application initializes various things.
We don't see this issue in Windows at all.
I'm going to submit this as a bug directly to Unity, but wanted to put it out there in case other people have seen something like this and it was due to user error.
Thanks!
There are two related, but different things here:
a) crossdomain.xml which is a file issued by a web server when it accepts HTTP traffic.
b) A socket policy file, which is served on port 843, and is used to allow the webplayer to make socket connections to a server. A webserver is not used to serve this file.
These things do get frequently muddled up. If you are using the WWW class, then you'll need to use (a). If you are using sockets, then (b).
Your server does have a cross domain xml file on it, I was able to fetch it using curl. The errors you get come from the socket policy stuff, so I assume you're using sockets. I wasn't able to use telnet as per the docs to fetch the socket policy file, however. Note that the socket policy file isn't crossdomain.xml.
Thanks for your answer! Apparently I was misreading the docs - you're right in that 843 is only for socket issues.
However, we are not in fact using sockets anywhere. Additionally, this wouldn't explain why we have no issues with the Windows webplayer while we are stuck in some kind of infinite loop on $$anonymous$$ac webplayer.
Any other ideas?
BTW, I have to apologize. After your post, I did a search through our code, and apparently our touch screen library (UniTUIO) does use sockets. I'm going to do a bit more investigation and let you know if I figure out anything else.
Well, sure enough it appears to be caused by the touch screen library. Now at least we have something to go on in trying to track this down. Thanks Graham!
