Hello,

I am the Hive's main architect and software developer, and welcome to my first blog. I plan to use this blog to post information regarding programming practices and design ideas for the .NET platform. Just as a brief background on myself, I have been programming since 1997 in VB5, and have since moved onto C++, and .NET C#, java script, and CSS. I currently work at a fortune top 100 company managing global software development which helps produce over 30 billion dollars a year in revenue. If you are interested in hearing what I have to say, stay tuned as you may find some useful articles if you are in the development field or are interested in it. Please find my first entry below which shows how to use SSL in WCF to prevent data corruption:

Data corruption comes in many forms, and validating data on your server/database can be challenging depending on what you allow your application to store. The idea behind ensuring user data involves knowing exactly what shouldn't be in your database. This process is not always as easy as doing string comparisons, or perhaps file signatures. Preventing corruption can be done in a few ways but occasionally there may be a situation where it can not be adverted. Consider the following scenario.

Information from your application originating at a user's PC is sent up to the server using a windows service and then applied to a SQL database. This approach is common for many reasons including server security. However just because the data is sent to the server through a controlled interface (your application) it does not mean the data is guaranteed to be received correctly. For instance a lot of servers may have TCP Chimney Offloading enabled (http://windows.microsoft.com/en-us/w...himney-offload) which does help performance but just because it uses TCP (as well as SQL) does not mean the data is the same as when we sent it!

Once the server receives the data we could do some validation checks, but depending on how open your application is (for instance storing BLOBs/Filestreams) corruption may not always be detectable. A way to help prevent corruption is to actually enable SSL communication on your windows services and to SQL server. A recent issue at work manifested when a glitch in our server VM's network card's firmware where bytes were being shifted as they came into our services. At first we did not notice the corruption because in our binary data it was not always in the same spot and over large byte arrays it remains hidden.

Enabling SSL allows the .NET framework to apply encryption and detection at each endpoint. This is great for us because it allows the data to be validated by the network infrastructure on our platform during those processes. Byte shifts would be detected at this point and the communication process would fail and not allow this erroneous data to make it to SQL server. Unfortunately sometimes you have to learn the hard way Of course there are other alternatives besides SSL, however enabling SSL in a windows service/SQL is fairly straight forward and does not involve many code changes.