Coded – Web Development and Programming Blog

I recently had to design a Windows Service that connects to several game servers via UDP, gathers stats, and then updates a MSSQL database.

These stats were then made available in real-time on a web-site written in C# and ASP.NET.

Before Remoting

For the first version of the application, the web-site and Windows Service were completely independent. The web-site would just query the database and determine, or make a best guess about what was going on inside the Windows Service at that exact time. This worked pretty good, and although the database is now about 1GB in size and growing fast, I optimized it good enough for this to work in real-time without a hitch.

There was some caching going on, thanks to the OutputCache directive in ASP.NET, but surprisingly enough there were no performance issues.

After Remoting

All right, so because I needed to display some extra information about ‘online’ users, that the Windows Service knew about, but the database didn’t, I decided to have a look at .NET Remoting. This was my first time working with it.

These were the issues I experienced (as a Remoting newbie) when rewriting the Windows Service to be accessible via .NET Remoting:

1. The actual functionality of the Windows Service had to be moved to a separate Class Library (.DLL).
   If you wrote your Windows Service all in one .EXE you will have to move it out to DLLs. Ideally you would have a DLL for the actual functionality – let’s call this Business.dll -, and another DLL for the Remoting methods and objects – Remoting.dll. You then create wrapper methods and objects in Remoting.dll which delegate work to Business.dll.

   The reason you have to do this is that the ASP.NET web-site will need to know which methods and objects are available via Remoting, and how to access them. All you have to do now is add a reference to Remoting.dll inside the ASP.NET web-site.

   This would have actually been a good design decision in the first place, because the Firewall on the server that was running the Windows Service kept complaining about changes to the Service’s .EXE each time I updated and restarted it. After moving the code out to a DLL, the complaints stopped because the .EXE was just a wrapper and it wasn’t changed any more.
   



2. The Remoting Wrapper.
   Now you can create wrapper methods around Business.dll in the Remoting.dll Class Library. To enable remoting, you will need to create a class that inherits from MarshalByRefObject . I’ll supply a code sample for clarity:

   public class FragRankRemoting : MarshalByRefObject { public List<PlayerData> GetOnlinePlayers() { List<PlayerData> list = new List<PlayerData>(); foreach (Server s in ServerController.Servers.Values) { foreach (Player p in s.Players.Values) { list.Add(p.PlayerData); } } return list; } }

   This is actual code from a real application, but it should help you get started.



3. Using IpcChannel for Remoting.
   Because the Windows Service and Web Site were hosted on the same computer, I decided that the best Remoting channel to use is IpcChannel (Inter-Process Communication channel via Named Pipes). The alternatives are TcpChannel and HttpChannel, which I would recommend for situations where the service and web site are not on the same computer.

   The problem with IpcChannel is that it requires both the Windows User Account that is running the Windows Service, and the User Account that is running ASP.NET to be under the same User Group, otherwise you will get the following error:
   RemotingException: Failed to connect to an IPC Port: Access is denied.

   If you have complete control over the system and are certain that no other applications can interact with your service, you can work around this security measure by allowing users in the “Everyone” Group to access the IpcChannel. Here’s how to do it:

   Dictionary<string, string> props = new Dictionary<string, string>(); props.Add(“authorizedGroup”, “Everyone”); props.Add(“portName”, “FragRankChannel”); props.Add(“exclusiveAddressUse”, “false”); IpcChannel channel; try { channel = new IpcChannel(props, null, null); ChannelServices.RegisterChannel(channel, false); } catch { }
   Notice the exclusiveAddressUse property. I needed to add this due to intermittent problems which occured when the service crashed during debugging, and the Remoting channel didn’t get properly closed.
   



4. Connecting to the Service from ASP.NET
   In order to connect to the service in ASP.NET via Remoting you will have to create an .XML file with the following contents (this can also go in your Web.config if you want):

   <?xml version="1.0"?> <configuration> <system.runtime.remoting> <application> <client> <wellknown type=”fragrank.FragRankRemoting,FragRankLogic” url=”ipc://FragRankChannel/FragRank” /> </client> <channels> <channel ref="ipc" authorizedGroup="Everyone"> <clientProviders> <formatter ref="binary"/> </clientProviders> </channel> </channels> </application> </system.runtime.remoting> </configuration>

   All you have to do now is let the Remoting class know about your configuration file and you can start using it! It’s as easy as:

   try { // you only need to call this once for the whole life-time // of your application, any subsequent calls will result in an error // // please replace this try/catch block with a more // elegant solution in your application RemotingConfiguration.Configure(Server.MapPath(”.”) + ”\\web.config”, false); } catch { }</p> // now just instantiate your remote class FragRankRemoting r = new FragRankRemoting(); // and you can use it just like any other class, even if it is hosted remotely List<PlayerData> playersAll = r.GetOnlinePlayers();

That’s it, the Windows Service and ASP.NET web-site are now communicating through Named Pipes.

[tags]Windows Service, Remoting, .NET, C#, IpcChannel, Named Pipes, ASP.NET, IPC[/tags]