Adobe implemented a security update implemented for socket connections similar in concept to crossdomain policy files. This can have adverse effects on a project.
When a SWF file attempts to read data from a location different from where the SWF was delivered from it first makes a call for a crossdomain.xml. If the crossdomain doesn’t exist or the policy that it instructs does not allow the source domain where the calling SWF originated the service call will not execute; flash player denies the request from ever being made.
Socket connections follow a somewhat similar course of action. When a SWF attempts to make a socket connection to a computer at a location on a given port it first makes a request to that same server on its default port, port 843. If that port has an open socket server listening it sends a single packet with an XML node consisting of a specific node. This is meant to tell the socket server that it should respond with the socket policy. The XML that is then returned contains all the information about socket policy for that domain. This all happens behind the scenes when a socket connection is created from a SWF.
This is great because of the security layer that it puts in place for each domain, but can be an extra layer, especially when someone is just testing a socket connection. This can also be additionally frustrating as most developers may develop in flash builder or the flash ide directly; while great tools, inherently they ignore the security layers of crossdomain.xml and socket policy servers. While this may sound wonderful to can be problematic when going live or promoting to a web server the socket server connections will begin to fail.
This adobe knowledge base post discusses how to make sure that policy logging can be turned on. This allows any request that could use a policy request to be logged. This can help immensely to figure out where potential issues with policy files exist.
Vizzy is a java based flash tracer tool that is typically used to view the contents of the flash log output file written to be the debug player. It has a combobox that allows the output to swap from the flash log txt and the policy log file
Using these tools one should be able to figure out if a socket policy server is needed (or if there are problems with a crossdomain.xml file)
One gotcha that might be faced is that a socket policy server could be in place, it could even respond in the correct fashion, but if the actual socket connection is unable to be created after receiving the socket policy it may respond with an error stating that the request was not permitted by the socket policy server. This is difficult to isolate as the error message is not inherently inline with the actual problem.
While the solution may seem ridiculous; “Duh, start your socket server that you actually want to connect to” keep in mind that there can also be firewall settings that get in the way. While straight up computer builds by a lot of developers can have firewalls easily turned off, builds that are used on corporate domains may have firewalls turned on, or have ports locked down in firewall settings. Be sure to check your firewall settings and that your socket policy server has started and the actual socket server has started also. Also note that rebooting a machine may find firewall settings reset and socket servers needing to be started up again
Nate is currently a Senior Presentation Layer Architect at Razorfish Chicago. As an SPLA Nate: participates in technology leadership team and resource allocations, manage fulltime and contractor resources, represents technology for groups of brands across multiple clients, furthers development of standards within the office, architects project implementations and fosters community and mentoring.