PolicyAllowedDomains: notification of failed attempts

[Lapo]

Thanks for the detailed report.
As regards this line:

Code: Select all

Security.loadPolicyFile("xmlsocket://myserver.domain.com:443"); 

as you correctly pointed out, this way the policy will be request on port 443 which is SFS. The fact that it takes that long (3 secs) to grab the policy makes me suspicious that there's some other network problem.
SFS serves the policy instantaneously under "regular" network conditions, you can check it in a local/test environment.

One possible reason for that delay could be a DNS problem, since you are not using the server IP address but it's name. I would probably recommend to avoid DNS resolution to speed up the process.

Also, I would double check the delay problem by telnetting SFS:
telnet sfs-ip-address 443

You should get the response within milliseconds.

I would leave the Policy Server questions apart until I get a clearer picture of this delay issue

Let me know

[Ganius]

Hi Lapo.

I guess I should have expanded my previous response a little better. The 3 second delay is ONLY when I have the Socket Policy Server running. I see the connection to the policy server sit there for 3 seconds, THEN the connect comes through, and SFS's crossdomain policy files is served immediately. When I turn off the Policy Server (so nothing is listening on port 843), I get the SFS crossdomain file in around 500ms max. So the 3 second delay is ONLY occurring when Flash tries to get the policy file from port 843 (ie the Policy Server).

Regarding telnet, I get the Policy Servers' policy file in milliseconds (when using telnet sfs-ip-address 843) and the SFS crossdomain in milliseconds as well (using telnet sfs-ip-address 443 when the Policy server is on or off - does not matter).

Also I should point out that I'm running this example from within a web page (with allowNetworking: "all" param). When I run it from inside CS4 itself, (using <ctrl><enter>) it never even tries to access the Policy Server, and the SFS crossdomain file is returned immediately. Sorry for the confusion there!

I tried using the servers IP address instead of the DNS name in the test application, and this made no difference - around 1/2 a second to receive SFS' corssdomain policy file, and still 3 seconds delay (and no policy file) from the Policy Server.

In the meantime, I'll keep reading more Adobe docs and forums until my eyes bleed some more...

Thanks,
G.

[Ganius]

An update on what I've found:

According to this Adobe document (http://www.adobe.com/devnet/flashplayer ... print.html):

For any socket policy file that Flash Player requests automatically, if the host does not either answer or reject the connection attempt within 3 seconds, Flash Player will abort the attempt, assume there is no policy file at that location, log a warning in the policy file log, and move on to the next stage of socket policy file authorization. This timeout behavior helps protect Flash Player against waiting too long for a socket connection that will never succeed, but it does somewhat reduce Flash Player's robustness to temporary network outages, slow connections, heavily loaded servers, etc. If you know that a certain socket policy file, which Flash Player would otherwise automatically request, is available, you can avoid the 3-second timeout behavior by explicitly calling loadPolicyFile from your SWF file, providing the URL of that socket policy file. This will cause Flash Player to be patient in its attempt to retrieve that policy file, avoiding timeouts until the TCP timeout of 2 minutes expires.

So... when I try and use

Code: Select all

Security.loadPolicyFile(xmlsocket://123.456.789.012:443);
socket.connect("123.456.789.012", 443);

there is a 3 second delay (as I've been describing) and I get the following output in my policy.txt debug file directly from the Flash player:

OK: Root-level SWF loaded: http://www.mydomain.com/socket/socketTest.swf
OK: Searching for <allow-access-from> in policy files to authorize data loading from resource at xmlsocket://123.456.789.012:443 by requestor from http://www.mydomain.com/socket/socketTest.swf
Warning: Timeout on xmlsocket://123.456.789.012:843 (at 3 seconds) while waiting for socket policy file. This should not cause any problems, but see http://www.adobe.com/go/strict_policy_files for an explanation.
OK: Policy file accepted: xmlsocket://123.456.789.012:443
OK: Request for resource at xmlsocket://123.456.789.012:443 by requestor from http://www.mydomain.com/socket/socketTest.swf is permitted due to policy file at xmlsocket://123.456.789.012:443

And when I use this code:

Code: Select all

Security.loadPolicyFile(xmlsocket://123.456.789.012:843);
socket.connect("123.456.789.012", 443);

there is a 15-20 second delay in receiving the policy file from SFS and my policy.txt file looks like this:

OK: Root-level SWF loaded: http://www.mydomain.com/socket/socketTest.swf
OK: Searching for <allow-access-from> in policy files to authorize data loading from resource at xmlsocket://123.456.789.012:443 by requestor from http://www.mydomain.com/socket/socketTest.swf
OK: Policy file accepted: xmlsocket://123.456.789.012:843
OK: Request for resource at xmlsocket://123.456.789.012:443 by requestor from http://www.mydomain.com/socket/socketTest.swf is permitted due to policy file at xmlsocket://123.456.789.012:843

Hmmmm...

So this does fall in line with the time it takes to retrieve the policy file from the Policy Server in the browser - 15 seconds. It makes sense based on the excerpt from Adobe that it will time-out after 3 seconds unless you specify to specifically load the policy file via loadPolicyFile. OK, I can live with that. But it seems that it consistantly takes around 15 seconds to load this file from the policy server!! Surely this isn't right...??

So why would it take 15 seconds to retrieve the file by typing http://123.456.789.012:843 into the browser, and the same when using Security.loadPolicyFile(xmlsocket://123.456.789.012:843); in flash, yet be instantaneous via telnet?

Sorry for the long-winded post, just sharing what I've found...

Cheers,
G.

[Lapo]

Thanks for posting what you have found.

So why would it take 15 seconds to retrieve the file by typing http://123.456.789.012:843 into the browser, and the same when using Security.loadPolicyFile(xmlsocket://123.456.789.012:843); in flash, yet be instantaneous via telnet?

Wow, quite perplexing
I will try a couple of tests locally and see if I can reproduce the issue.
Will let you know what happens

[Lapo]

Tests done, problem acknowledged.
Also I might have found a little quirk in the Policy Server which could be the culprit. Not sure yet.
Can you do a couple of tests for me with the updated server?
Here you can download it.

Might do the trick.

[Ganius]

Ok, now it's gotten even stranger...

With the new Policy Server, when using:

Security.loadPolicyFile(xmlsocket://123.456.789.012:443);

I have the 3 second timeout appear in my logs, but I see the following in the DOS box of the Policy Server:

Got req: <policy-file-request/>(22)
Serving policy to: id=xxxxxxxx.xxxxxxxxxxx.xxxxxxx.x.x, remote=mypc.domain.com(/123.456.789.012:1234)

This output in the policy server appears right away when it connects, then I see the connected users = 1, stays on 1 for 3 seconds, then goes back to 0, and at this time my Flash movie continues and then outputs SFS' policy file. So it seems the Policy Server gets the request immediately, and serves it back immediately as well (although in reality I hit the 3 second timeout and get nothing on my client end).

When I use

Security.loadPolicyFile(xmlsocket://123.456.789.012:843);

I get pretty well the same output as described above - ie the Policy Server output says it's serving the policy file immediately on connection, however it takes the 15-20 seconds to send the response back to my client.

So essentially the same as I've been describing in previous posts, yet this time the Policy Server is immediately saying it's sending a response.

But, when I put http://123.456.789.012:843 in the browser, it takes 15 seconds, and I get nothing returned in the browser (I used to get the policy file show in the browser), and no output at all from the Policy Server. Also, when I telnet now, I also get no output in the Policy Server indicating it's sending anything (although in both cases here I do see the connection being made as the ConnectedUsers increases), but now I don't get any policy file shown in my telnet session either!

I'm not sure what to make of this, but I know that with this new policy server I at least see it saying it's recieved a connection and has sent the file back, although not through telnet or the browser, only through my test swf.

Hope this helps!

Cheers,
G.

[jatin_anand]

Hi Ganius,
Even i am facing the same 1085 error code issue. I have not installed any Socket Policy Server. I just tried an example (tat too came with the zip file i downloaded from this site). Its giving some tag closing error.

TypeError: Error #1085: The element type "body" must be terminated by the matching end-tag "</body>".

Could you please help me out here? I am really trying hard to come over it but no success as yet.

Any one there, please spare some of your valuable time...

Regards,
Jatin

[Lapo]

Ganius:
I've done more tests capturing the network traffic and updated the PolicyServer which was not functioning correctly. I think this update should solve the issue... what a pain in the butt
Download updated PolicyServer

jatin_anand:

Your problem seems unrelated. Could you please provide all the details of the problem by starting a new post?
Make sure to read our posting rules:
http://forums.smartfoxserver.com/viewtopic.php?t=3307

[Ganius]

Hi Lapo.

I downloaded the updated Policy Server and it works great - I get the correct policy file sent back from port 843 in milliseconds (it's actually so fast I don't even see the connection being made to the Policy Server GUI but I know it's received the file from the Flash policy log). I also tried to put domains that would not work in the policy.xml file, and it denied my requests as it should.

So it looks like this is running beautifully now!!

Thanks very much for your help here!

Cheers,
G.

[Lapo]

Great!

[Boing]

We also experience the problem, that the client "wastes" 3 seconds waiting for the policy file on port 843 (validated with the Wireshark tool).
When we tried running your policy server on our debian system we experienced the following problems:

On startup

Exception in thread "main" java.awt.HeadlessException
at java.awt.GraphicsEnvironment.checkHeadless(Unknown Source)
at java.awt.Window.<init>(Unknown Source)
at java.awt.Frame.<init>(Unknown Source)
at java.awt.Frame.<init>(Unknown Source)
at javax.swing.JFrame.<init>(Unknown Source)
at it.gotoandplay.policyserver.ServerGUI.<init>(ServerGUI.java:11)
at it.gotoandplay.policyserver.PolicyServer.showInfo(PolicyServer.java:56)
at it.gotoandplay.policyserver.PolicyServer.<init>(PolicyServer.java:42)
at it.gotoandplay.policyserver.Main.main(Main.java:21)
Oct 21, 2010 11:42:30 AM org.xsocket.stream.MultithreadedServer$AcceptorCallback onConnected
INFO: server listening on /0:0:0:0:0:0:0:0:843 (xSocket 1.2.1)

An when a client connects:

Oct 21, 2010 11:42:37 AM it.gotoandplay.policyserver.PolicyProtocolHandler onData
SEVERE: null
org.xsocket.ClosedConnectionException: connection 9266d9bd.12bce2b11a3.661bb95f.s.1 is already closed
at org.xsocket.stream.Connection.write(Connection.java:667)
at org.xsocket.stream.Connection.write(Connection.java:582)
at org.xsocket.stream.Connection.write(Connection.java:573)
at it.gotoandplay.policyserver.PolicyProtocolHandler.onData(PolicyProtocolHandler.java:60)
at org.xsocket.stream.NonBlockingConnection.onDataEvent(NonBlockingConnection.java:749)
at org.xsocket.stream.Connection$HandlerCallback.onDataRead(Connection.java:1574)
at org.xsocket.stream.io.impl.IoMultithreadedHandler$IOEventHandler$2.run(IoMultithreadedHandler.java:161)
at org.xsocket.stream.io.impl.IoMultithreadedHandler$TaskQueueProcessor.processTask(IoMultithreadedHandler.java:277)
at org.xsocket.stream.io.impl.IoMultithreadedHandler$TaskQueueProcessor.run(IoMultithreadedHandler.java:265)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)

Another question:
Is your policy server here http://www.smartfoxserver.com/temp/PolicyServer.zip the same that is linked at the bottom of this page http://www.smartfoxserver.com/whitepape ... index.html ? We used the latter.

Best regards!

[Lapo]

The policy server requires a GUI but your OS seems not to be running any Windows server. I think that's the problem.

As regards links I'd suggest to stick with the link in the white paper

[Boing]

Thanks for the quick reply.

Well.
I just couldn't imagine that your policy server is restricted to Windows systems (respectively GUI systems) since the SFS isn't and I don't see the necessity.
That means we have to look for alternatives?

I would think that a lot of SFS users currently live with the "3s longer than necessary" connect, simply because not knowing it could be avoided.

[Boing]

for those interested:
starting the policy server with -nogui does the trick...