I ran across an interesting site containing an algorithm that predicts your sex based on browser history. This algorithm uses demographics from popular sites, determines which popular sites you have visited by digging through your browser history, and then predicts what gender you are based on your browsing habits. 

This algorithm sounds a lot like an adaptation of the Turing Test. But instead of predicting which of two participants in the test is human, this one predicts what gender they are. The Turing Test has long been the standard for judging the intelligence of a computer system, even though it is flawed in many ways.

The Turing Test, and this entertaining site attempting to guess my gender, are similar in nature to the way that traffic shaping/management devices have traditionally identified applications. And like this browser gender test, they are often wrong.

That's because traditional traffic shaping/management devices originally based their assumptions on ports and protocols. If it was served on port 80 over HTTP, then it must be HTTP. These devices learned, eventually, that this information was not enough upon which to base identification when every application out there attempted to circumvent corporate firewalls by running on port 80 over HTTP.

The devices, however, were primarily packet-based. This meant they inspected individual packets, which may not carry enough information to make a determination regarding which application is being used. They tried "signatures", but found that even that failed to accurately identify the majority of applications.

That's why flow-based inspection is so important. We call that application fluency, and it is the ability to examine and inspect flows rather than packets. Flows are built by reassembling packets into a full application message at which time it is inspected and a determination made on what it really is.

Application fluency is the cornerstone of a wide variety of technologies related to application delivery. Without application fluency you can't provide web application firewalling, you can't optimize and accelerate specific applications like SharePoint or Exchange, and you certainly can't intelligently route application messages. In order to apply policies, whether related to security or acceleration or routing, you first have to determine what the application is. The same security and routing policies that should be applied to IM (Instant Messaging) are not necessarily the right ones to apply to your web application. Even though both may be transported over HTTP and through port 80. You need to be able to accurately identify the application before you can start applying policies.

Application delivery requires application fluency; intelligence. It can't just look at ports or protocols to determine how best to deliver an applications. It needs to understand the application, to really know - not just predict based on a few attributes - what it is in order to ensure that it is delivered fast and securely.

If it doesn't, you could end up with a solution that might decide your SharePoint application is really PeopleSoft much in the same way the test decided I was probably male (61% likelihood).