Advertisement

Important change to Sockets in Silverlight 2

An important note for those using Sockets in Silverlight 2.  In beta 1, Sockets were limited to site-of-origin (meaning you could only connect back to the same host that served up the Silverlight application).  This has changed in beta 2 to allow your Silverlight application to connect to any server exposing some Socket connections.

One important note, however, is that a policy implementation has been added.  This policy implementation affects not only cross-domain Socket calls, but site-of-origin ones as well.  So if you are using Sockets, you must have a policy implementation in place.

The policy implementation is done via a similar file mechanism as HTTP-based cross-domain requests.  The policy file looks similar and here is a basic example:

<?xml version="1.0" encoding ="utf-8"?>
<access-policy>
  <cross-domain-access>
    <policy>
      <allow-from>
        <domain uri="file:///" />
      </allow-from>
      <grant-to>
        <socket-resource port="4502-4506" protocol="tcp" />
      </grant-to>
    </policy>
  </cross-domain-access>
</access-policy>
Notice how you can restrict the ports here (note: Sockets in general in Silverlight are limited to ports 4502-4534).

This policy information must be made available on a TCP port request on port 943.  Any Socket request will first look for that policy information to respond on this port 934 request.  If successful, the remaining communication will be allowed.  If not, the communication will fail.

UPDATE: I accidentally typed "934" originally as the port -- it is 943.

There is no code change you need to have in your current Socket implementation other than implementing a Socket policy server to respond to the policy request.  I’ll be covering the basics of sockets on a video over on the Silverlight community site which will demonstrate and provide code on doing this implementation.  Stay tuned for that one.

Hope this helps.


This work is licensed under a Creative Commons Attribution By license.

  1. 6/7/2008 2:29 AM | # re: Important change to Sockets in Silverlight 2
    Nice! Is the same functionality being implemented for standard HTTP requests, or are they still same server only at the moment?
  2. 6/7/2008 1:05 PM | # re: Important change to Sockets in Silverlight 2
    In future releases of Silverlight will supported sockets be expanded? Will the need of this policy file be removed? I am creating a silverlight client for an application I am not in control of, so far in beta I have had to create a relay server that accepts communication on ports 4502-4534 and sends all information to the real destination. This will not work in production.

    I think Silverlight needs to have an option to open up ports with a prompt akin to the local storage expansion, this will allow the creation of a wide variety of clients and will not expose a security risk.
  3. 6/7/2008 1:21 PM | # re: Important change to Sockets in Silverlight 2
    @m.david: There already exists a similar policy file for cross-domain communication via HTTP -- been there since Beta 1. We also support a limited set of Adobe's crossdomain.xml structure.

    @Kellen: the policy structure will remain. your relay server doesn't have to accept on the wide range of ports you can specify a specific one to use for communication. Additionally, the prompting for 'open port' really wouldn't help since the network owner has to enable communication through firewalls, etc. Sockets may not be ideal in every situation, but where they can be used for specific scenarios (i.e., multi player gaming, etc.) it is a great choice.
  4. 6/9/2008 2:19 AM | # re: Important change to Sockets in Silverlight 2
    There's a video up at;

    http://mtaulty.com/CommunityServer/blogs/mike_taultys_blog/archive/2008/06/07/10493.aspx

    which does the very basics of getting a socket client/server up and running with a policy server.

    Mike.
  5. 6/10/2008 4:28 AM | # re: Important change to Sockets in Silverlight 2
    Thanks for the port number Tim,

    I've published a substantial example based around a ticking stock list that demonstrates the Socket support in Silverlight 2 Beta 2 including handling the new policy requirements in the same server on a separate thread.

    http://petermcg.wordpress.com/2008/06/10/samples-updated-to-beta2/

    Peter
  6. 7/6/2008 12:18 PM | # re: Important change to Sockets in Silverlight 2
    Do we need a policy server if we are targeting the local machine via 127.0.0.1?

    If so, can I set up local IIS on 127.0.0.1:943 and where do I put the file?

    Can I use localhost for:

    <allow-from>
    <domain uri="localhost" />
    </allow-from>

    I started out looking for a simple way to communicate with other programs on the local computer and this is turning into an 'adventure'

    -Jay
  7. 7/6/2008 2:24 PM | # re: Important change to Sockets in Silverlight 2
    @Jay: yes, a policy server is required in all socket communication now. Take a look at http://silverlight.net/blogs/msnow/archive/2008/06/26/full-implementation-of-a-silverlight-policy-server.aspx
  8. 9/27/2008 8:26 PM | # re: Important change to Sockets in Silverlight 2
    Most of my development is within the scope of highly interactive webpages.

    For web pages, mostly I use Flash these days because it is the best cross browser, cross platform system we have. I really hate to say that because I really think Flash is poorly done. Just an indication of how much crap we have to put up with to get things to work in a browser.

    Now I have no SilverLight experience at the moment, but I tend to pick up any technology that works in browsers.

    Now about policy files. Flash serves policy files on port 843 and you are telling me SilverLight serves policy files on port 943. Is the world not nuts enough alreay ?

    I will say something good about flash. It allows you to serve socket policy files on any port. So all you have to do is connect to a socket on a given port and flash automatically sends the policy request to the server listening on that port. So this is good. You can have the same server providing policy files as well as providing for normal socket connections.

    It appears to me, that in SilverLight, policy files must be served on port 943. Also, in SilverLight, sockets are restricted to ports 4502-4534. There is no such port limitation in Flash. Typically we listen on 8080 because it tends to be more corporate friendly.

    I am trying to keep this short.. lol... I have not even gotten to the real problem yet... I will save it for my next post...

    Don
  9. 9/27/2008 9:09 PM | # re: Important change to Sockets in Silverlight 2
    Gee, now all we have to do is ask corporate america to unblock ports 843 and 943 and 8080 and 4502... yeah right

    So my real issue is being able to serve corporate america the same interactive experience without them having to unblock any ports.

    Let's assume corporate users can only get out on port 80 (HTTP). It's not a valid assumption that these corporate users will be able to get out on ports 843, 943 or any other port except port 80.

    Suppose you want to do server push thru HTTP.

    You can do this with an HTTP request object. In Flash it is called URLStream, in a browser it is called XmlHttpRequest. I don't know what its called in SilverLight. The Flash implementation of HTTP uses the browsers implementation and of course the same is true for XmlHttpRequest.

    Browsers impose strick limitations on the number of open HTTP request you can have. This can be anywhere from 2 to about 6 open connections at any one time. For a given browser, these request are shared between all open browser windows. If you keep an HTTP request object open, subsequent HTTP request are subject to failure. If flash did not use the browsers HTTP implementation this would not be a problem.

    So flash URLStream is a bad way to keep an HTTP request open. The browsers XmlHttpRequest object suffers from the same problem. I assume the same is true for whatever SiverLight uses.

    Now in flash, you could use a socket to connect on port 80, but there is no way to authorize this connection unless you first connect to another port and authorize from there. But as I said, I are assuming you can ONLY get out on port 80. If you can connect to port 80, you can do your own HTTP request and all is good and no limitations.

    Currently in flash, you cannot authorize a socket connection from an HTTP crossdomain.xml file, so you cannot do a socket connection on port 80 if all ports are blocked on the client machine other than 80. Assuming client users can only get out on 80 is the best assumption. Its not like corporate america is going to open ports 843 or 943 just because Adobe or Microsoft recommend it. Authorizing a socket connection to port 80 is not even possible in SilverLight at any time because of the restricted port range. I can run my server on port 80 if there is no web server such as apache running and flash clients can easily connect to it, but this is not what I want.

    I can easily keep an HTTP connection open and everything is good. The user gets the same experience.

    Server push thru open HTTP works just fine, except for the existing limitations mentioned above.

    Possible fixes:

    o - Get rid of the restricted nature of open HTTP connections. This currently can range from 2 to about 6 depending on browser and other things. Once HTTP connections are used up, any additional HTTP connection attempts are put into a queue and wait for one of the open ones to close.

    o - If Flash would do its own HTTP handling, there would be no HTTP connection limits.

    o - Allow an http policy file to authorize a socket connection on port 80 so we can do our own HTTP. This actually works best.

    o - Allow as a special case socket connections on port 80. In this case, you must provide valid HTTP headers etc. and you are dealing directly with the HTTP server (apache). Provide some mechanism so that the policy file can be delivered in this special case.

    Considering the past 10 years of abismal browser development, it would be great if we could actually take more than just a baby step and move into the 21st century.

    Thanks Tim,

    Don
  10. 9/28/2008 8:05 PM | # re: Important change to Sockets in Silverlight 2
    Don: great feedback and stuff we've been hearing as well! We're looking at some of these exact things for a future version of Silverlight, but the Socket implementation will be as-is for Silverlight 2.
  11. 11/10/2008 6:59 AM | # re: Important change to Sockets in Silverlight 2
    I've posted some of my thoughts here:

    spoox.org/.../silverlight-and-socket-support-wh...

    By the title, you may already get a hint at my take on it.. It might come across a bit edgy, but it was just a few days worth of frustration building up and being released :)
  12. 11/10/2008 8:02 AM | # re: Important change to Sockets in Silverlight 2
    Rune: Good feedback (and known). Of course we're constantly looking to improve this and have ideas for the future versions of Silverlight.
  13. 11/10/2008 9:36 AM | # re: Important change to Sockets in Silverlight 2
    This is a bit off-topic, but I saw something related mentioned in the post above by Don, with parallel http calls and browser limitations.

    I've experienced that if I do 3-4 parallel calls to a web service (using basicHttpBinding - same service, different methods), my logging on the server will indicate that 3 of the methods finished within the fraction of a second, while one takes somewhat longer (e.g. 20-30 seconds - this is expected, it's a slow one).

    However, on the client side, the async callbacks take the same amount of time to be triggered as the longest lasting web method call.

    E.g. MethodA, MethodB and MethodC takes 2 seconds, while MethodD takes 20. They all more or less get their *Completed async callback methods called after 20 seconds, when MethodD finishes.

    To me it looks like the calls are queued up in a request bus inside SL somewhere, instead of returning independently. (Since the web server indicates they're all called at the same time)

    Any explanation?

 
Please add 1 and 1 and type the answer here:
First time here? You are looking at the most recent posts. You may also want to check out older archives. Please leave a comment, ask a question and consider subscribing to the latest posts via RSS or email. Thank you for visiting! (hide this)