Forum Moderators: open
Also, are there issues with sniffers and search engines if the sniffers are being used to enhance users experiences as opposed to manipulating them?
As a rough outline, you first grab the current time, then you download a bit of highly compressed binary data, and then you grab the time again and do the math. The reason to use highly compressed data is to avoid any error that modem compression would introduce. The author I read used just a piece of code taken from within a highly compressed jpeg file, and then commented it out.
This method measures the exact connection speed in the moment the test is performed - but it can be thrown off by a fluctuating bandwidth. Also, it's going to be more accurate at telling the difference between 28.8 and 56.6, for instance, than getting a fine-tuned measure of broadband connection speeds. But that's probably OK, since with streaming media, you care more about separating out the lower speed conndctions than getting any precision on the high speed folks.
Here's a tutorial page on bandwidth detection [emediacommunications.biz] where I read about this method.
**********
In sniffing situations of all kinds, I've also been cautious that search engines may not like the redirect, no matter that my motives are good and my heart is pure.
My solution has been not to redirect all the traffic. That is, no matter what factor I'm sniffing for, I choose one of the most common situations and let those visitors get their content from the default page, and I only redirect the other configurations.
This has, so far, served me very well.