Silverlight Networking

Analogy categoryAnalogies

The Two Networking Stacks Inside the Silverlight Plug-in

Silverlight ships with two independent networking implementations: the browser HTTP stack, which routes requests through the host browser's own networking layer and therefore inherits its cookies, cache, and authentication cookies automatically, and the client HTTP stack, which Silverlight implements itself using raw sockets and bypasses the browser entirely. You choose between them with WebRequest.RegisterPrefix or the BrowserHttp/ClientHttp members of WebRequestCreator, and the choice affects everything from which HTTP verbs are available to how many concurrent connections you can open to a single host.

🏏

Cricket analogy: It's like a team choosing between using the stadium's official broadcast feed, which carries the same commentary and replays everyone else sees, or setting up an independent camera crew that captures its own raw footage with different angles and limits.

WebClient and HttpWebRequest

WebClient is the simplified, event-based API most Silverlight tutorials start with: you call DownloadStringAsync or UploadStringAsync and handle the corresponding Completed event, and WebClient handles headers, encoding, and response buffering for you. HttpWebRequest sits one layer lower, giving you access to request headers, the HTTP method, and streaming request or response bodies through BeginGetRequestStream and BeginGetResponse, which matters when you need to POST a custom content type like JSON to a REST endpoint or set headers WebClient does not expose, such as a custom Authorization scheme.

🏏

Cricket analogy: It's like the difference between a club batter who just walks out and plays each ball on instinct, versus a professional opener who studies the bowler's field placement and adjusts grip and stance for full control before every delivery.

Sockets and the Cross-Domain Policy File

For low-latency scenarios such as streaming stock tickers or multiplayer game state, Silverlight exposes System.Net.Sockets.Socket for raw TCP connections, but only to ports 4502 through 4534 by default, and only after the target server has served a policy file, typically retrieved on port 943 as an XML document granting the calling domain permission to open a socket. This restriction exists because unrestricted outbound sockets from a browser plug-in would turn every Silverlight app into a potential vector for port-scanning or abusing internal network services, so Microsoft deliberately narrowed the allowed port range and required an explicit opt-in from the server.

🏏

Cricket analogy: It's like a stadium only allowing broadcast vans to plug into a specific set of designated power outlets around the ground, and only after security has verified the crew's credentials against a pre-approved list.

Cross-Domain HTTP and clientaccesspolicy.xml

Ordinary HTTP calls made with WebClient or HttpWebRequest to a domain other than the one that served the XAP are subject to the same cross-domain checks used by WCF: Silverlight first requests clientaccesspolicy.xml, and if that is missing, falls back to crossdomain.xml for compatibility with existing Flash deployments, from the root of the target domain. If neither file grants access to the calling domain and headers being sent, the request fails silently from the application's perspective with a SecurityException surfaced in the Completed event's Error property, which is the single most common cause of 'my Silverlight app works locally but not when deployed' bug reports.

🏏

Cricket analogy: It's like a broadcaster requesting footage from a rival network's archive; before any clip is handed over, the requesting network must present a signed usage agreement on file, or the request is quietly declined.

csharp

// Client HTTP stack + custom header, streaming a POST body
WebRequest.RegisterPrefix("http://", WebRequestCreator.ClientHttp);

var request = (HttpWebRequest)WebRequest.Create("http://api.example.com/orders");
request.Method = "POST";
request.ContentType = "application/json";
request.Headers["Authorization"] = "Bearer " + token;

request.BeginGetRequestStream(reqResult =>
{
    using (var stream = request.EndGetRequestStream(reqResult))
    using (var writer = new StreamWriter(stream))
    {
        writer.Write("{\"sku\":\"SKU-102\",\"qty\":2}");
    }

    request.BeginGetResponse(respResult =>
    {
        var response = (HttpWebResponse)request.EndGetResponse(respResult);
        using (var reader = new StreamReader(response.GetResponseStream()))
        {
            string body = reader.ReadToEnd();
            Deployment.Current.Dispatcher.BeginInvoke(() => StatusText.Text = body);
        }
    }, null);
}, null);

The client HTTP stack does not send browser cookies or reuse the browser's authenticated session by default, so switching from WebRequestCreator.BrowserHttp to ClientHttp to gain header control can silently break cookie-based authentication that worked when the app used the browser stack.

Silverlight offers two HTTP stacks: browser HTTP (inherits cookies/cache) and client HTTP (full header/verb control, no cookie inheritance).
WebClient is simpler and event-based; HttpWebRequest gives low-level control over headers, verbs, and streaming.
Raw sockets are restricted to ports 4502-4534 and require a policy file served on port 943.
Cross-domain HTTP calls require clientaccesspolicy.xml (or crossdomain.xml) on the target domain, checked before every request.
A missing policy file causes calls to fail with a SecurityException in the Completed event's Error property, not a compile or obvious runtime error.
Switching stacks can break cookie-based auth because ClientHttp does not share the browser's session automatically.