GEO Targeting Made EASY! (For PHP)

[BusinessGeek]

I haven't been programming for years now and my skills are a bit rusty, to say the least, but one thing I can remember from reading binary files is that it can consume a lot of cycles when it's not done properly. I remember I once wrote a program in VB that would seek for specific strings using the elmination method you mentioned above, but the larger the file got the more it ate up from the process. Of course using "Windows" I learned a much faster way to conduct the search is to simply load the entire file into virtual memory where it can be read scores faster than through a physical medium.

Looking back on my earlier college days I remember one of my profs. was explaining the difference between reading from virtaul memory (such as RAM) and physical memory (such as your hard drive). It has a lot to do with distance really. The closer the data is to the cache memory the faster the process can cycle it. Even though you're still moving the data from the hard drive to the virtual memory by loading it in the RAM (which then later moves into cache memory) you're loading it in chunks. However, with a binary seek you're loading tiny portions (more calls to the physical memory are created).

However, the only time that would actually be a problem is when you are process the function at a tremendous rate. I don't see how that would be a problem here but I haven't tested out your code either.

[KLB]

Okay, I've spent half the day cleaning up all of my scripts and changing the order in which they are called to reduce server overhead as much as possible. I don't think this script was a problem per say but that it was the last straw on the camel's back. I'm currently running on a cleaned up version of the function that does a binary compare without reading the file into memory. I seemed to get the best overall results with it. If anyone has suggestions as to ways I could further clean up this script I'd appreciate feedback.

Here's the latest version of it:

	function ipcountrycode($ip){
		$ip=ip2long($ip);

		$low = 130;

		// Open the csv file for reading
		$csvfilename="ip2country.csv";
		$fp = fopen($csvfilename, "r");
		fseek($fp, 75000, SEEK_END);
		$high = ftell($fp);
		
		while ($low <= $high) {
			$mid = floor(($low + $high) / 2); // C floors for you
			
			//Seek to half way through
			fseek($fp, $mid);
			
			// Moves to proper line
			//if($mid != 0){
				$line=fgets($fp);
				//}

			// Read line
			$line=fgets($fp);
			$line = str_replace("\"", "",$line);
			$ipdata = explode(",",$line);
			if ($ip >=$ipdata[0] && $ip<=$ipdata[1]){
				$low=$high+1;
				}
			elseif($ip >=$ipdata[0]){
				$low = $mid + 1;
				}
			else {
				$high = $mid - 1;
				}
			}
		fclose($fp);
		$line="";
		return $ipdata[4];
		}

[rpanella]

That function looks fine to me. I don't see how it could be any more server intensive than your original function, and should infact be less.

Perhaps just the added load of you implementing geotargetting for the last few days is why they contacted you, not because you changed to doing a binary search. If this is the case, I would think it might be time to start thinking about upgrading your server.
________
Mflb

[KLB]

Rpanella, I came to the same conclusion as you about the server load. The scripts on my site represent years of accumulation and I decided it was time to strip out some detritus. It is amazing how much code bloat can creep in over time. I've spent most of today reviewing the code in my includes and using performance monitor on my laptop to see how much load my scripts put on Apache as I make little tweaks. I'm starting to see some tremendous improvement in my scripts and I haven't had any more complaints from my web host in regards to my Geo targeting. I do think the tweaks I made in my last version of the script helped as well.

[KLB]

In my quest to reduce the impact geo location has on the server I "got smart" and decided to set a cookie that retains this information from page view to page view. This way if the user allows the cookie it will eliminate the need to constantly call the geo location function. Of course the security draw back is that the user can modify the cookie, so I'd recommend being careful how this method is deployed and to recognize this limitation. I figure in the case of geo targeting ads, this isn't really a big deal.

Here is the code to set the cookie and call the function:

	if(strlen(addslashes($_COOKIE['GeoLocation']))==2){ 
		$strCountryCode=$_COOKIE['GeoLocation'];
		}
	else{
		$strCountryCode=ipcountrycode($REMOTE_ADDR);

		//	Sets cookie for geo location.
		$HostDomain=str_replace("http://","",$_SERVER['HTTP_HOST']);
		$SetCookieExpire=mktime() +604800; //Set cookie for one week
		setcookie ("GeoLocation", $strCountryCode, $SetCookieExpire, "/", $HostDomain, 0) ;
		}

[Westech]

I like your cookie idea, but as you said, the security issue is a little scary. I wouldn't want to get tossed out of YPN over someone playing around with the cookies. Another idea might be to use a php session variable. I think I'm going to look into this for my sites.

[KLB]

The cookie could be made a little more "secure" by simply encoding and decoding the country code. The cookie could contain two parts, the "encrypted" cookie and half the "salt". The other half of the "salt" could be hard coded into the source code. Then all you would need to do is combine the salts to decode the cookie. If the cookie was invalid geo targeting could be established via PHP. This would certainly address 99% of any mischief.

In regards to the YPN concerns, I really don't see this as a realistic concern for most sites out there. At most, I would expect people would modify the cookie to show them as being from some country that is unpopular with advertisers to trick the site into not pushing ads.

[KLB]

Okay I found a serious flaw in my function that was causing the country code not to be returned for a large number of IP addresses. Apparently PHP's built in ip2long() function frequently returns negative values, which have to be fixed. Since I didn't know this (and apparently neither did the person I based my script on) about 50% of IP addresses were not returning a country code.

The fix is quite simple. All one needs to do is swap out the line of code that converts IP addresses into integers:

// Replace
$ip=ip2long($ip);

//With
$ip=sprintf("%u", ip2long($ip));

I've updated the original code I posted to reflect this fix and added a couple of other minor fixes that were causing some IPs not to return country codes.