Hi,
Has anyone had scalability issues with the use of crossdomain.xml and a Flash client?
We’ve got a custom built flash client served by a web page. We are having firewall problems with some of our users, so we set OpenFire up on a separate server running on port 443. However, to go to a separate server, Flash requires crossdomain.xml to be served via a socket. So we’re serving crossdomain.xml from port 80. (not via HTTP but via a OpenFire. We had to modify FlashCrossDomainHandler.java to change the port to 80).
Our problem is that about 1 in 5 attempts by our Flash client to connect fail. Once it connects the server works fine. Looking at the code, I see that the handler for crossdomain.xml is single threaded. We’re hypothesizing this doesn’t handle users connecting at the same time very well.
Has anyone else hit this issue? Would appreciate tips on alternative methods to serve crossdomain.xml via sockets in a high-performance manner. We’re in a classroom environment. We expect situations where dozens of students (if not hundreds) will all try to log in at the same time.
WILL
It may be too late for this to be helpful but if not…
I believe you are mistaken in your comment that to run openfire on a separate server from your client you must serve the crossdomain file from openfire itself. An alternative exists that worked for me (after several hours of investigation and frustration) and I suspect this approach would eliminate the scalability issues you are seeing. Assuming the server you have openfire running on also acts as a webserver running over port 80, do the following:
- place a crossdomain.xml in the web root folder - the file should look similar to
<?xml version=“1.0”?>
<!DOCTYPE cross-domain-policy SYSTEM “http://www.macromedia.com/xml/dtds/cross-domain-policy.dtd”>
<cross-domain-policy>
<allow-access-from domain="*" to-ports=“5222” secure=“false” />
</cross-domain-policy>
*note that the to-ports attribute is critical
- ensure you can reach this file through a browser - i.e. http:///crossdomain.xml 3. in your flash / flex application, add the line Security.loadPolicyFile(“http:///crossdomain.xml”); before you attempt to connect to openfire
Step 3 is required - flash does not attempt to load the policy file by default for socket connections the way it does for normal web resources.
I hope this works for you - I know how frustrating security issues can be!
Hi,
Thanks for your detailed response!
We’ve moved on but I’ll write back anyway. Actually, this isn’t sufficient. If you serve the crossdomain.xml from HTTP, then you can only access the xml socket from port 1024 and above. (at least with the security model in the most recent Flash 9 player). To serve xmlsocket traffic < port 1024 (e.g. for firewall compatibility) you must serve crossdomain.xml via an xml socket.
We’ve experimented with many different approaches at this point. This turned out to be a real hassle for us! I had no idea an embedded web chat feature would be so difficult to roll out large scale. In the end we use Jabber via a Flash plugin (with crossdomain.xml served from OpenFire) but degrade to http-polling if this doesn’t connect. (http-binding wouldn’t work due to the browser limit on http connections). And http-polling isn’t supported in OpenFire, so we moved to ejabberd 2.0.
Best, WILL