PeterCallaghan.com ⍾

Occasionally, it’s handy to know what your public IP address, which is the IP address assigned to you by your ISP.  Most home users will have a Dynamic IP address, meaning they won’t always have the same IP address when connected to the internet.  People may use this public IP address for all sorts of things, such as remote connections (e.g., for tech support), gaming, or just to see if their address has changed.

There are a few websites out there that will show you what your IP address is, and by far, the best one I found was http://www.whatismyip.org/.  This was a favourite of mine, simply because all it did was show your your IP address… nothing else.

I found that the site has become unreliable.  Quite often it does not work from the office, and I have to use one of the other sites to check my address.  whatismyip.org was always super quick because all it had to load was your IP address, so at most, a 15 byte page.  Because it had become unreliable, I decided to write my own page that mimics the functionality.

The first one I’ve written in ASP.NET, as this is what I primarily program in, and I have my own site to which I can easily add a new page.  So, without further ado, here’s my ASP.NET version of What Is My IP.

The code for the page is as follows:

Now, some will notice this is an ASHX page, which is an ASP.NET generic handler.  The reason I chose this filetype was simply because I wanted the resulting output to be as small as possible, and an ashx file is perfect for this.

There are two things going on here.  First, context.Response.ContentType = “text/plain” sets the content type of the page to a plain text document, so there is no html fluff bloating the page.  The other thing is to get the IP address, and I use one of two ways to get it.  context.Request.UserHostAddress or context.Request.ServerVariables(“REMOTE_ADDR”).  I chose to try both ways, simply because both return the public IP address, and if one fails, then you get a second chance at showing it.  I’m really not sure which one works more than the other, and I will do some logging on this to determine which is more reliable.  Check back in a few weeks for an update.

Now, because I’d decided to write about this page on my blog, and my blog is using WordPress (and hosted on a server that handles php), I decided to have a look at the same thing in PHP.  I’ve been meaning to learn more about PHP, so this was a good opportunity.  So, the resulting page was my PHP version of What Is My IP.

The code for the page is as follows:

It’s glaringly obvious that the PHP version is a lot less lines of code for the same result (mind out I could cut out 4 lines of .net code if I took out the if/else statement).  This has made me even more keen on learning PHP.

There you have it.  At least another couple of places you can check your IP address if you need to know.  It will also be interesting to see if this page starts ranking for “What is my ip” in google.  As always, hopefully someone finds this useful.

I am the lead developer for an online business, and we primarily use ASP.NET for our programming, but also use other web technologies such as Javascript and jQuery to support our web application.  One of the tasks our site does is to gather a list of data from several different sources, and show the combined results in a table, sorted by price.

We do this by our search results page loading with a summary of the search criteria, and then doing a jQuery Ajax call to a handler page that actually goes to get the data and return the results in a formatted HTML document to the calling page.  Now, we wanted to extend on this to add a second table of results from another source, but the new table will be different to the current table of results.

We wanted to do this via another ajax call, and to combine the results together.  The issue I came across was returning the results from the two ajax calls, and displaying the combined results.

A normal javascript (or other procedural programming language) would return the results to a variable for each function, then you can do something with those variables.  When this approach was taken with the ajax calls, the variables that were to hold the results were empty when used to display the info on the page.  The reason was the ajax call was still running when the javascript got to the bit to use the results, as is the nature of an asynchronous function (it runs in the background while other process can continue).

This might seem like a fairly straightforward answer, but if you’ve not used ajax a lot, it can be easily missed.  Anything that uses the response from an ajax function needs to be handled in the “Success” portion of the ajax call.  You can call other functions from here, but don’t rely on the results being available outside of the ajax call, as you can’t guarantee when the call will finish.

The answer to combine the results from two ajax functions was to nest the two functions.  Such as:

$.ajax({
  url: 'searchresults.aspx',
  data: 'searchfor=something',
  cache: 'false',
  success: function(search){
    $.ajax({
      url: 'tools/extrainfo.ashx',
      data: 'moredetails=on+something+else',
      cache: 'false',
      success: function(more){
        countContinue=false;
        $('#tblSearchResults').html(search + more);
        Init();
      },
      error: function(){
        countContinue=false;
        $('#tblSearchResults').html(search);
        Init();
      }
    });
  }
});

What’s happening here:

1. The first ajax function looks for a response.  It gets a response, so the success handler function runs.
2. In the success handler, a second ajax function looks for a different response.  On success, the two results are combined in a table on the html page
3. If the second ajax call fails, it will just show the results from the first ajax call.

This works, for us.  You could go down a different path and keep the two ajax calls completely separate, and have two sections that the results are updated to.  This would not have worked for us, as we wanted to keep the results in a single section of the calling page.

I have a feeling this is a fairly unique issue to our web application, but you never know, someone else out there might find the info useful.

Yay for my first WILT post 

Last week, I realised that I am not using my site enough, and I need to be putting more content here.  Partially for my own reference, as it’s often good to keep things you think are interesting in the one place, for easy reference.  What better place then your own website?

I just had the idea of posting more of the things I learn, be it related to programming, or anything else of interest.  Some posts will be very short, just a snippet of some information of anecdote I found interesting, so someone else might find it interesting too.  Others will be a little more in depth, especially if it’s a programming related post.

So, today I am launching a new category… WILT – What I Learnt Today.

Stay tuned for my first WILT post.