I spoke with Jasmine at the beginning of the month. I hope she doesn't mind me pasting what she had to say:*Daniel wrote:any update?
Complete rewrite of perl scripts (xmlsockd scripts for flash), better handling of multiple connections in all three versions of the script (xmlsockd, xmlsockd-basic, xmlsockd-threaded). A lot of changes (and testing) already done and just awaiting a final review before committing it to svn.
Todo (before packaging & release of new version):
Why Silverlight 4? Why not all Silverlight versions? why not v3 as well?
- Rewrite flash/actionscript plugin to use Socket() rather than XMLSocket(), bundle as flex project, rather than flash project, this way it could be compiled with free/open-source tools and not exclusively dependent on Adobe Flash Professional to author the .swf
- Backporting some changes/additions made to the Java plugin portion of the standalone version, particularly:
- Detection of NIC interfaces, and associated MAC (hardware) Addresses
- Optional detection of IPv4/IPv6 addresses of the detected NICs (if possible)
- Adding Microsoft Silverlight 4 plugin, using either "Client HTTP Handling" or Sockets, though most likely the latter because ClientHTTP probably still inherits "system-wide" proxy settings (if set) regardless of browser used; ex. IE proxy settings (== network settings in control panel) in Windows. And so, the changes made to the flash plugin will allow both flash & silverlight to use the same perl daemon script (both can use plain sockets, no xml), though only flash will use the XMLSocketPolicy authorization part.
See: Network security access restrictions in Silverlight
In Silverlight version 3 for a connection request using System.Net.Sockets to the site (cross-domain or site of origin), the Silverlight runtime tries to open a connection using TCP to a well-known port (port 943) on the target site.
That means another custom socket policy server script listening on port 943 is needed to authorize connections, which is undesirable. Port 943 is below 1024, and so the script will also need to be run as root (on *nix systems at least) to be able to listen on that port, which is not possible in many virtual hosting environments.
On the other hand:
In Silverlight version 4 for a connection request using System.Net.Sockets, an application can choose instead to retrieve the policy file via the HTTP protocol on TCP port 80 instead of the custom TCP protocol on port 943.
It is a safe assumption that most phpbb forums would be running on HTTP server listening on port 80 (the standard), and so publishing a socket policy file would be as easy as FTP uploading a file to the site.
Though, first, I need to verify that Microsoft really means what it said in the following statement:
The policy file for sockets must be stored in the "clientaccesspolicy.xml" file at the root of a web server that responds for the resolved IP address of the target connection request.
Because if that is as it sounds, that means Silverlight would be requesting http://ip.ad.dr.ess/clientaccesspolixy.xml rather than http://virtualhostdomain.tld/clientaccesspolicy.xml (similar to the relatively-new crossdomain.xml support for Java's HTTPRequest class) which could be troublesome in many virtual-hosting environments.