|
home | contact us | about us | |
| Socket Connection Between Silverlight Plugin and Desktop Application (by Lou Burne, last updated 22-FEB-2011) The Brief This page is for developers who want to develop Silverlight plugins that connect by TCP sockets to applications (or services) running on the user’s PC. An example of making this technology useful is having a small TAPI application sitting in the system tray, which informs the Silverlight plugin when the phone is ringing. The Silverlight plugin can download customer details and display them to the user before the user picks up the phone. Obviously this breaking-out-of-the-sandbox has a few security implications, and if you do try to socket an application from a Silverlight plugin, you will get a flat rejection. A connection like this is dependent on having the correct security policy in place. Security Policy To connect Silverlight to an application, that application must have a security policy file that identifies the incoming connection as acceptable. Below is an example of such a policy file. This policy allows TCP connections on port [PORT], from Silverlight plugins hosted on the domain [DOMAIN]. Obviously the markers [DOMAIN] and [PORT] would have meaningful values. For example, [DOMAIN] could be ”www.microsoft.com” and [PORT] 4501. [DOMAIN] can also equal “*”, which permits all domains, which is useful for testing.
This policy file is served to the Silverlight plugin from the application, NOT from Silverlight or the hosting website. The server that serves the policy file is called the Policy Server. The Policy Server When Silverlight connects to a listening application, the underlying Silverlight security layer first attempts to retrieve the policy file from the application. This is done on port 943, and this brief socket connection is separate from the intended connection to the application. If connection on 943 is not made, or if the policy file is not returned or is corrupt, either the connection to the application is denied access, or Silverlight kind-a locks up. Either way, a working connection has not been established. In summary, your application or service, apart from serving application data, is also going to have to serve the policy file on port 943. Here is a policy server we made earlier. The code was developed in Windows 7, VS2010 and C# .Net 4.
Open the PolicyServer.cs file, and we can go through it. There are two classes defined in the PolicyServer.cs file – PolicyServer and PolicyConnection. The PolicyServer class has a listening socket which accepts incoming connections on port 943, wraps them as a PolicyConnection object, and leaves the PolicyConnection object to handle the forthcoming policy request. At the top of the PolicyServer class definition you will notice inclusion of the namespace SilverMessaging, which is the namespace for definitions of the message class, message queue class and socket parameters class. The SilverSockets Solution, which makes use of these classes, is described below. In the static constructor of PolicyServer, the policy file clientaccesspolicy.xml is loaded. The markers for [DOMAIN] and [PORT] are replaced with the live values. It is assumed this file does not change during runtime so it is only loaded the once, and held as a static member, ready to be served. It is not large. In the sample project I have set this file to always be copied to the output directory, but a smarter way might have been to make it an embedded resource. I have implemented the IDisposable interface. I find socket classes easier to implement if they are single-state, that state being connected. So if the socket object exists, it is connected. PolicyConnection, the second class defined in the file, exists solely to handle policy requests, which it does by firing back the policy buffer on the client connection, and then closing the client connection. The SilverSockets Solution The sample project, SilverSockets, demonstrates how to implement the PolicyServer.cs, so you can test it out.
The SilverSockets Solution includes three projects, BrightPlugIn, SundryWebsite and MonitorApp. There are also some files in folder SharedFiles which are included in both the BrightPlugIn and MonitorApp builds. These files are SilverMessage.cs, SilverMessageQueue.cs and SilverMessageParams.cs. SilverMessage.cs is a definition of the message sent between BrightPlugIn and the MonitorApp. One of the benefits of TCP sockets is the efficiency of transmission. For the SilverMessage class, messages are serialized to binary. (They are too short to apply compression.) SilverMessages can be textual messages sent between the MonitorApp and BrightPlugIn., or of type Panic, Hello, Goodbye and Error. The Hello message is sent periodically by the MonitorApp to ensure the socket connection is valid. The Goodbye message is sent prior to the BrightPlugIn or MonitorApp closing. SilverMessageQueue.cs is a list of SilverMessage objects. Socket functions run in a separate thread from the UI thread, and yet it is the UI that has to respond to them. So SilverMessageQueue has to be thread-safe. SilverMessageQueue also includes a thread-safe event which is fired when new messages are added to the queue. The window that picks up this event can then pull new messages from the queue until it is empty. SilverMessageParams.cs is a static class containing the port and domain for the connection between BrightPlugIn and MonitorApp. Project: BrightPlugIn BrightPlugIn is the Silverlight plugin project. The socket connection class is LocalSilverTalk. Note the line:
This tells the socket layer that the policy file for this connection will be retrieved from the target application by TCP socket. The alternative is Http, and downloading the policy file on port 80. MainPage.xaml/cs is the main window class, including buttons for connecting, and sending messages to the MonitorApp. Project: SundryWebsite SundryWebsite is the website that hosts the BrightPlugIn. GOTCHA 1: When developing the website side of the project, make sure your DevStudio is running under Administrator privileges. To do this, right click the Microsoft Developer Studio 2010 in the start menu, and select Run as Administrator. GOTCHA 2: Also on the website development side, setup IIS on your machine, and use this as your testing website. (There is an option in the project properties to “Use Local IIS Web Server”.) Do not use the development web server. Using IIS as your server, you can test your connection by entering the domain name of your IIS website into the policy file. Doing the same with the development web server does not yield the same results. Project: MonitorApp MonitorApp is a small WPF application that serves data to any connected BrightPlugIn, and implements the policy server on port 948. Listening for connections is done by the LocalDesktopServer class. When a connection is accepted, the connection is wrapped as a LocalDesktopClient object. LocalDesktopClient handles communications with each connected client. MonitorApp minimizes to the system tray. For more details on doing this, see the Tray Icon Notes. GOTCHA 3: If during testing your Silverlight plugin fails to connect, you must stop the web server and restart it again before testing another set of parameters. You cannot modify the MonitorApp, edit and continue, and then try to connect again. Here are the code files one more time.
MORE INFORMATION MSDN - Working With Sockets in Silverlight MSDN - Network Security Access Restrictions in Silverlight MSDN - Sockets Class (Silverlight) |
 |
© 1998-2012 Broccoli Products Ltd Reg Number: 2895355 Reg Office: 27 Old Gloucester Street, London. WC1N 3AX |
Privacy Policy Copyright Notice Liability Disclaimer Contact Us |
|