 |
History
| Log In
|
|
|
|
[
Permlink
| « Hide
]
David Rorex - [04/10/08 07:31 PM ]
I've got the same problem. It's a big obstacle to certain types of applications that want to check if a socket server is available by attempting to connect to it.
yes, same problem. this really needs to be fixed ASAP.
This is a MAJOR functionality restriction in the Flash Player. I have been working on an application for months, only to be stoped on this, what one would expect to be, a trivial bug. (And should be trivial to fix)
As this is a Flash Player Bug, and Flash Player usually has a resonable time between releases.. 9.0.124 has just been released and still has this bug. What is the likelyhood and time frame for the next Flash Player (10) release? I am running into the same thing, this is a huge issue for us, it is very hard to recreate, but when we have tens of thousands of people trying to connect every hour, it is a big problem that a few of them get rejected. I get this error in the security policy file (over and over again):
OK: Searching for <allow-access-from> in policy files to authorize data loading from resource at xmlsocket://localhost:5222 by requestor from http://localhost:3000/flash/chat.swf Error: Request for resource at xmlsocket://localhost:5222 by requestor from http://localhost:3000/flash/chat.swf has failed because the server cannot be reached. The server is up and running, I can telnet to 5222 and issue the command manually and it works. Running wireshark shows that flash player is never making a request on 5222 again, and at the same time saying that the host cannot be reached. Also, I am not using loadPolicyFile, but just letting Flash automatically request the policy file when it does the connect call. I just tried this on the new FlashPlayer10 under linux, and this bug still appears to be in there...
I would consider this a resonably trivial bug to fix, so I am a little surprised.. Must I beg? This bug kills all my development on Flex for my Apps, as its all based around socket comms. James I've found a (horrible, inefficient, hacky) workaround:
1. Your main SWF, instead of attempting to connect to the socket via .connect(), instead calls ExternalInterface.call("checkSocket") 2. A javascript function checkSocket() uses DOM manipulation (manually, or via some library such as SWFObject), to load a small "SocketCheck.swf" 3. SocketCheck.swf simply tries to load the policy file, and connect to the socket server 4. SocketCheck.swf uses LocalConnection to report back to the main SWF, if it succeeded or failed 5. If, and only if, the main swf gets a success, then it will attempt to connect to the socket 6. If there was no success, ExternalInterface.call() is used again, to unload the checkSocket.swf, and then go back to step #1 Note: The SocketCheck.swf MUST be loaded in a separate element on the HTML page. You can not simply load it into your main swf. I really recommend against this workaround, since it's slow & puts extra load on your server (many requests for SocketCheck.swf). Hopefully adobe can fix this bug. Thanks David,
Gee man, thats a UGLY hack. I can see where you are coming from.. To tell the truth, I could make a proxy on the application server if I consider going to this trouble.. I would prefer it just to work the way it is suppose to. And as FlashPlayer10 is resonably close, and Betas are available now, I was hoping that I could lean on that.. As it SHOULD have this bug fixed. Its not like its a difficult one to fix. Thanks for your suggestion however, James I am having this exact same problem. Server isn't up, fails to get the policy file and then my .swf starts looping trying to reconnect, but even though I'm calling loadPolicyFile before each attempt (until I connect) I will never connect because I missed it the first time and all subsequent calls are ignored.
I suppose you could remove and readd the swf from the dom to reset things each time, but it seems like overkill for what seems like a minor oversight of the loadPolicyFile design. I have found a work around like David Rorex, but a simpler one. I'm working on a javascript library I'm calling JSXMLSocket that provides the XMLSocket interface to javascript and it has an initialize method
obj.initialize = function () { if ( swfobject.hasFlashPlayerVersion( this.minFlashVersion ) ) { var swf = [ this.swf, '?jsInstanceName=', this.instanceName, '&random=', new Date().getTime() ].join('') var params = { allowscriptaccess: 'true', swliveconnect: 'true', }; var attributes = { id: this.id, name: this.id, bgcolor: "#ffffff" }; swfobject.embedSWF( swf, this.id, "1", "1", "9.0.0", false, params, attributes ); } else { // TBD hook to handle inadequate flash player version } }; Now when we reconect and we have NEVER connected before, I just call initialze again to replace the flash movie with itself in the dom (via swfobject - http://code.google.com/p/swfobject/) obj.reconnect = function() { this.log( 'Will attempt to reconnect in ' + this.reconnectWait + ' seconds' ); if ( this.haveConnected ) { setTimeout( this.instanceName + '.connect()', this.reconnectWait * 1000 ); } else {4a // we need to rewrite the flash movie due to a bug with the current Flash Player // as of 9.0.124. I've commented on a existing bug in Adobe's bug tracking // system // http://bugs.adobe.com/jira/browse/FP-67 setTimeout( this.instanceName + '.initialize()', this.reconnectWait * 1000 ); } }; There is some overhead, but its better than falling on your face and telling your user that they can't connect. I ran into this issue also. This, in conjunction with another apparent problem I just reported ( https://bugs.adobe.com/jira/browse/FP-269 ), are pretty much showstoppers for our application. Reliable network communications that don't require a manual restart are mandatory for us.
I believe this issue also applies to URLLoader policies; killing your network connection before starting the app, and then turning it on again, produces the same behavior. This is unacceptable behavior and is making me consider leaving Flash.
Guys, could you please give us an update on this issue?
FP10 beta2 is already here and this bug has not been fixed yet. Thanks! My workaround for this bug is pretty simple. I have added another functionality to my java policy server - it listens not only for adobe's <policy-file-request/> but also for my custom '<is-server-online/>' request. The request is made by simple php script with error reporting turned off (so in case of policy server is down - i'm getting correct reply instead of warnings):
error_reporting(0); $site = "xxx.xxx.xxx.xxx"; $port = yyy; $fp = fsockopen($site,$port,$errno,$errstr,5); if(!$fp){ echo "error"; }else{ $out = "<is-server-online/>\0"; fwrite($fp, $out); echo "success"; fclose($fp); } So before my flash application tries to load policy, im checking if server is running by loading above php script. In case of success application is loading policy. Otherwise it's not. Hope its understandable. Apologies for not reponding in a while, we have reproduced the issue and are investigating. This is high on the list to fix. Thank you for you input and suggested work arounds.
YAY!!
When you know, could you please post a comment here on how we can get access to this fixed version of flash player. For example. You will see it in FP-10, due currently in x months. Or You can access a developer version from X. Please try out. Thanks, James To workaround this problem, we separated the SWF with socket communication from the content SWF. This enabled us to reload/re-embed the socket SWF upon receiving the security sandbox error.
This seem to have solved our problems and we can keep a persistent TCP connection (that can retry if connection closes). These two attachments show packet captures using the command "tcpdump -vvv -A dst port 843" from the client. One shows a successful policy file request, and the other shows a failed request. Captured using Flash plugin 9.0.124 on Linux kernel 2.6.18.
My experience with this bug has it occurring even if the policyfile server is up but might have at one time been down.
Both the packet dumps in my attachments were taken while the policy server was up and serving requests. In fact, the server responds to the inbound connection in both cases but errors out in the failed scenario because the "<policy-file-request/>" is never pushed by the client. i.e. a successful policy file request is made in 6 packets, with the 3rd pushing the policy-file-request request. A failed request is made in 4 packets.... connects to the policy file server successfully, but sends FIN as its third packet. Here is the relevant portion of code: {code:ActionScript} Log.notify("Attempting to load socket policy file at xmlsocket://"+address+":843",this); Security.loadPolicyFile("xmlsocket://"+address+":843"); Log.notify("Completed attempt to load socket policy file.", this); this.xmlSocket.addEventListener(Event.CLOSE, xmlSocket_close); this.xmlSocket.addEventListener(Event.CONNECT, xmlSocket_connect); this.xmlSocket.addEventListener(DataEvent.DATA, xmlSocket_data); this.xmlSocket.addEventListener(IOErrorEvent.IO_ERROR, xmlSocket_ioError); this.xmlSocket.addEventListener(SecurityErrorEvent.SECURITY_ERROR, xmlSocket_ioError); {code} And the corresponding logs for the failed request: {noformat} Wed Sep 17 2008 03:33:12 AM NOTIFY: com.foo::Main.as: Initializing GameShow Build $Rev: 14524 $ Wed Sep 17 2008 03:33:13 AM NOTIFY: com.foo.net::BlasterClient.as: Attempting to load socket policy file at xmlsocket://local.foo.com:843 Wed Sep 17 2008 03:33:13 AM NOTIFY: com.foo.net::BlasterClient.as: Completed attempt to load socket policy file. Wed Sep 17 2008 03:33:13 AM NOTIFY: com.foo.net::BlasterClient.as: Attempting to connect to xmlBlaster. Wed Sep 17 2008 03:33:13 AM NOTIFY: com.foo.net::BlasterClient.as: Completed attempt to connect to xmlBlaster. Wed Sep 17 2008 03:33:13 AM NOTIFY: com.foo.resources::ResourceManager.as: Asset loading completed .... <SNIP> .... Error: Failed to load policy file from xmlsocket://local.foo.com:843 Warning: Timeout on xmlsocket://local.foo.com:8443 (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.Error: Request for resource at xmlsocket://local.foo.com:8443 by requestor from http://local.foo.com/apps/gameshow/GameShow.swf has failed because the server cannot be reached. {noformat} As long as ya'll (Adobe) are fixing this, please fix the other problems that I'm having with sockets being made unreliable by the security agent getting in between me and a connect.
This new one I just reported has to do with the connect failing if the name takes too long to resolve (even though the browser didn't give up in fetching the SWF!): http://bugs.adobe.com/jira/browse/FP-658 The older one, which appears to have received no attention as far as I can tell, despite me providing the code necessary to reproduce it, is a mysterious failure to connect after n reconnects: http://bugs.adobe.com/jira/browse/FP-269 My take is that reliable network communications should be considered fairly key to this whole Flash thing... This build should be fixed in the current public beta release found on labs.adobe.com
My experience indicates that while this problem has been fixed for IE it still exists in the FireFox runtime using FP 10.0.12.36
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
Bug
Resolved
B
Security.loadPolicyFile() attempts to load file only once
