Introduction
As you may already know, Silverlight 4 beta has been released and it has many new features. One of the most important features is net.tcp binding support. Now in Silverlight 4 we can communicate with WCF web service using net.tcp protocol. You may have noticed the many blog posts or articles that came out with a title similar to this : Silverlight 4 – WPF killer. If I can choose the one most important feature in Silverlight 4 beta that can kill WPF apps I will choose the net.tcp support.
If you have already worked with Silverlight 3 you probably have some WCF web service. In Silverlight 3 you have been limited to use basic http binding for communication with WCF service. One of the major performance improvements in Silverlight 3 was the possibility to add binary encoding to basic http binding that serializes and deserializes your messages in binary format. Net.tcp binding uses binary message encoding by default.
Why to use net.tcp binding ?
A key benefit of net.tcp binding is the performance. If you want fast Silverlight applications that communicate with your WCF service in your secure intranet environment you will probably use this binding.
This net.tcp binding for now is intended to be used in intranet environments. Because this protocol is build on top of Silverlight sockets implementation it has same network security restrictions. Silverlight restricts the ports of TCP socket connections to the range 4502 – 4534 . Because of that it requires environment where we can control the firewall configuration. In this way we can easily monitor Silverlight applications traffic and maintain the security of our corporate network.
Net.tcp protocol in Silverlight also does not support transport level security. For example, we can’t have SSL communication.
Net.tcp duplex support
Another key benefit of net.tcp binding is the support for duplex communication. Now we can use same HTTP polling duplex proxy from the previous version of Silverlight and just specify that the proxy will use net.tcp binding and everything will work. We can even make WCF service that uses HTTP polling duplex protocol for Internet clients and uses net.tcp protocol for Intranet clients. The programming model is the same like before and is simple to use.
Problems with installation
When I tried to debug an example of a WCF application using net.tcp binding I ran into the following problem. I constantly received the error : The protocol 'net.tcp' is not supported .
It seems that Visual Studio Integrated Cassino server supports only HTTP activation. So after that I tried to deploy my application into IIS.
Only IIS7 has support for net.tcp binding so you must have IIS7 installed on your machine.
WCF services with net.tcp binding inside IIS7 are hosted on Windows Process Activation Services (WAS). To enable WAS hosting on IIS7 for net.tcp you must do a few things:
1) You must enable Windows Communication Foundation Non-HTTP Activation. One important feature of IIS is the ability to activate a web application when an HTTP request for that application is received. A similar feature exists in IIS7 for net.tcp , but it may not be enabled by default.
2) You must set the application poll to use Framework 4 enabled poll and must enable the net.tcp protocol.
3) You must also enable port or ports in range 4502 – 4534 for net.tcp binding.
Or you can skip step two and three and do it faster and quicker using command prompt. IIS provides a new command-line utility to configure Web sites : Appcmd.exe. The command bellow will update the configuration file for WAS, applicationHost.config, with new binding for the default web site :
%windir%\system32\inetsrv\appcmd.exe set site
"Default Web Site" -+bindings.[protocol=
'net.tcp',bindingInformation='*']
After that you need to check if net.tcp listner adapter service is running. You can do it by executing the following command sc query NetTcpActivator or look in services :
If you get the following error : Could not find a base address that matches scheme net.tcp for the endpoint with binding NetTcpBinding. Registered base address schemes are [http].
the problem might be because you haven’t specify a base address for net.tcp binding in service web.config file. You need to specify a base address similar to this :
endpoint address="net.tcp://localhost:4502/wcservice/Service.svc"
If we want to generate proxy on client side and we have only specified net.tcp binding in our service, we must set up the Metadata Exchange (mex) endpoint to use the net.tcp binding :
<endpoint address="mex"
binding="mexTcpBinding"
contract="IMetadataExchange" />
Also if we want to allow to share the same port on different services, we must enable the port sharing service for net.tcp. We can do it by executing the following command in command prompt : C:\sc.exe config NetTcpPortSharing start= demand
After that you must allow Silverlight applications to communicate over TCP. In order to do that the server must explicitly allow such a connection. This is done by exposing a TCP socket policy over TCP port 943.
This is how an example policy file for sockets looks like :
<?xml version="1.0" encoding ="utf-8"?>
<access-policy>
<cross-domain-access>
<policy>
<allow-from>
<domain uri="*"/>
</allow-from>
<grant-to>
<socket-resource port="4502-4506" protocol="tcp" />
</grant-to>
</policy>
</cross-domain-access>
</access-policy>
To make our life easier, Tomasz Janczuk from Microsoft has created a free template for console applications that serves like TCP socket policy server.
You can later make windows service that will do the same thing on hosting server. This console application receives requests from Silverlight clients and returns socket policy file to the client. You must run this console app on server to enable Silverlight applications to communicate over TCP.
After that we are up and running….
Summary
Net.tcp binding support in Silverlight 4 beta is one of the most important new features. It brings us excellent performance but with some security constraints such us port limitations. Because of that it is recommended to use it for Intranet applications in secure environments where you can control firewall settings. It can be great alternative in such environments for HTTP polling duplex or for Basic HTTP binding. This protocol supports a simple to use WCF duplex programming model. I hope that in the near future we will see a much better support for net.tcp binding in Silverlight without security constraints.