Zoals je wel kon verwachten heeft al de miserie bij die setup te maken met security en meerbepaald met de ingebouwde windows firewall. Ik zeg het niet rap maar in dit geval READ THE FUCKING MANUAL (het helpt)

http://learn.iis.net/page.aspx/309/configuring-ftp-firewall-settings/

As it turns out the string.GetHashCode() has no random factor and is fully based on the characters in the string. This means it will always return the same value for the same string It also has a good spread and on top of that it return int32 values instead of  some horrible base64 encoded string. It can therefor be very usefull for storing word hashes in search tables. I used string.GetHashCode() to generate wordhashes for searchbarrels. All of this worked very well from .NET 1.1 over .NET 2.0 to 3.0 and 3.5. 

Last week however we installed a beautifull new frontend: dual quad core, 16 GB ram AND OFCOURCE 64 BIT! Everything worked fine execpt for the searchbarrels. No errors or crashes just no result. Some log digging pointed to the hashes. Apparently string.GetHashCode() return different hashes in 64bit then in 32bit. This turned out to be a rather big problem. google didn’t help much at first so we turned to reflection. As we suspected the System.String implementation of GetHashCode() is different in the 64bit framework. 

This is very good news because now it has nothing to do with the 64bit itself and we can simply create our own method or extension method that will still generate the same hashes even on a 64bit machine

    /// <summary>
    /// Similar to String.GetHashCode but returns the same
    /// as the x86 version of String.GetHashCode for x64 and x86 frameworks.
    /// </summary>
    /// <param name="s"></param>
    /// <returns></returns>
    public static unsafe int GetHashCode32(string s)
    {
        fixed (char* str = s.ToCharArray())
        {
            char* chPtr = str;
            int num = 0x15051505;
            int num2 = num;
            int* numPtr = (int*)chPtr;
            for (int i = s.Length; i > 0; i -= 4)
            {
                num = (((num << 5) + num) + (num >> 0x1b)) ^ numPtr[0];
                if (i <= 2)
                {
                    break;
                }
                num2 = (((num2 << 5) + num2) + (num2 >> 0x1b)) ^ numPtr[1];
                numPtr += 2;
            }
            return (num + (num2 * 0x5d588b65));
        }
    }

While Microsoft has updated the bot’s version number (from 1.1), it isn’t changing the name, it notes. But what’s interesting is the part of the post from Microsoft that reads:

We do not anticipate any problems related to our increasing emphasis on MSNBot 2, but the unexpected can’t always be avoided, no matter how hard you try! As such, we wanted to preemptively alert folks to the most effective way to report bot and crawling issues to Bing’s support team in case they arise.

Problems? What sort of problems? Is the BingBot going to become self-aware, Skynet-style? Microsoft gives no details. I’m scared.

Bron :  http://www.techcrunch.com/2009/07/17/ignore-that-scary-msnbot-its-just-the-friendly-bingbot-unless-it-attacks/

volledig artikel : Microsoft stelt gamen zonder controller voor