Since my job description was to bring Direct’s software into the fast lane of innovation, we moved closer to becoming a Microsoft shop.  There were some grumbles around the office, but IMHO, Microsoft has ALWAYS provided the best design environment (Visual Studio) mixed with plenty of online documentation (MSDN) and examples (CodePlex).   My predecessor had signed us up for the Microsoft Action Pack  (Microsoft Partners Program) which gave us in-house licenses of nearly every one of their products from Office to Servers.  It only came with 5 licenses of Vista Business and no Windows 7, so we couldn’t test in every environment.   Luckily, our Action Pack subscription was up and we decided to go with the Empower for ISV (Microsoft Partners Program) which is designed for either new businesses or existing businesses who have decided to design their products for Microsoft platforms.  I had to jump through a few hoops to complete enrollment (curse you website requirements!) but it all paid off because an added bonus was 40 hours of support/consultation with MS experts and 5 seats of Visual Studio 2008 Professional AND VS 2010 Beta w/ .NET 4.0.

Microsoft’s .NET technologies first came out right as I was graduating but didn’t catch my eye at that point.  My last shop was using Visual Basic 6.0 with “plans” of moving over to VB.NET.    Upon arrival at Direct Systems, I had free reign  to follow my hearts desire as far as strategies and tools for our system migration.  My vision was to have a fully connected system that was network aware, centrally maintained and able to track the presence of users and services available.  With Windows Communication Foundation (WCF), formerly Indigo, included in all .NET versions since 2.0, I was provided with a structural framework that seemed to fit my needs.

I knew nothing of networking and web services before I started developing with WCF.  I had some good resources, but it was like boot camp trying to wrap my head around some of the different concepts.  The hardest part was deciding on one of the various implementations to be the FRAMEWORK of my new system.  TCP or HTTP or NamedPipes or MSMQ or P2P.  Luckily with WCF it’s easy to implement all of them side by side, but I needed one to be the core.

I had been leaning towards Peer2Peer due to it’s self governing mesh topology and inherent multi-casting.   The main drawback SEEMED to be decentralization.  I wanted to be able to not only monitor but centrally dispatch data and messages to the peers on the mesh.  I decided to move forward and start implementing P2P.  In the process I developed a Logger monitor app and a CentralService service application that maintains the system from the server.

I ran into a stumbling block when I tried to establish a P2P connection from our development Windows Server 2003.  At first I thought it might be firewall settings, but it wasn’t.  Turns out the problem lies in the way the mesh governs itself.  The technology is call Peer Name Resolution Protocol (PNRP) and comes in XP, Vista and Server 2008 under Advanced Networking.  Unfortunately, it didn’t come included in Windows Server 2003!  Microsoft has added the ability to circumvent this and create your own custom resolver that you can self host in a 2003 environment.  This seemed like a headache having to write custom code that an update could have patched.  After some discussion with Bob, I started to implement the custom resolver and had a moment of clarity!  I could just host the resolver inside the CentralService.  The act of looking for the custom resolver was a way for the peer node to make contact with my service and start sharing information.

So in the end, what seemed like a weakness was actually my biggest asset!

Facebook

Facebook