WHY ??
-- This project came out of a need to occasionally have access to the test server in the office from the outside world. Since this test server is connected to a Shaw Cable modem through a router, the IP address assigned to it changes intermittently. As an interim solution we used one of the free Dynamic DNS client/server solutions, but we found that the reliability was poor and we wanted to control the process from our own web site and provide an automatic link.

Since this was not intended as a commercial or even a general access web site, it was not necessary to provide an actual domain name for it, just a working link from inside an established web site. In fact the extra expense and hassle of an actual domain name linked to this server was not required.

This project is still under development so the page will be used as a general repository of links and information while we work on it. Keep checking back if you are interested in the process.

Once the project is completed, we will make the code and configuration available for a small fee.

 

Implementation and Requirements

-- Define a function or series of functions, that would allow the test server to report its dynamic IP address to the primary web server. Define a function or series of functions which allow the primary web server to write that new IP address to a HTML link on a web page and display it to the web user. Since we did not want to write proprietary code for each test server or primary web server, we decided to use PERL as the CGI interface of choice.

The process required was broken down as follows:

Function 1 - Test Server Reports Dynamic IP Address
Since the PERL language has a built in "environment variable" reporting function which will report a variety of HTTP environment variables including the REMOTE_ADDR address of the computer making the call to the CGI script, it was easy to have the test server call that script on the primary web server and have the script log the REMOTE_ADDR address.

Step 1 - Test for Remote IP Address -- PERL Script

In the listing of variables the one we are interested in is the REMOTE_ADDR (about halfway down the page)
The other variable of interest is the QUERY_STRING which will identify our remote server.

Step 2 - Filter Remote IP Address -- PERL Script

We don't need to see all of the variables, just REMOTE_ADDR. Added some formatting.

Function 2 - Primary Web Server Records Dynamic IP Address
Once the primary web server has produced the "environment variable" report, it needs to log that REMOTE_ADDR address so that it can produce a link. Rather than having it save it to another file and then have to open that file to run the next level, we decided to make it continue with the process in the same PERL script.

Function 3 - Primary Web Server Builds the file DYN_DNS.JS
The next step was to have it write to a JavaScript file that could be called from a web page as a library function. This section of the PERL script would have to:
1. Open a file "DYN_DNS.JS" in the appropriate directory with the file handle ready to write over (not append) the contents of the preceeding version of the DYN_DNS.JS file.
2. Write the default JavaScript header and function definitions into the file DYN_DNS.JS
3. Write the new IP address into the "window open" function in the "href location" section of the function.
4. Write the closing section of the default Javascript function into the file DYN_DNS.JS
5. Close the file "DYN_DNS.JS" with the file handle so that the dynamic IP address link is now to the new location.

This would conclude the PERL script from the primary web servers end of things.

Function 4 - Web Page Calls the JavaScript Function DYN_DNS.JS
Simple enough, the web page needs a line in the HEAD section of the page to include the JavaScript file DYN_DNS.JS and then requires an "A HREF" tag calling that JavaScript library function directly to link to the dynamic IP address of the test server in the office. The connection below shows what I had in mind.

Call JavaScript Function DYN_DNS.JS
All this function actually does is call a function which opens a window and accesses the IP addressed site from within that window.

NOTE 1: When you load this JavaScript function from the directory into the Web page, do remember to pay attention to the case of the filename you stored the function in. "SITELINK.JS" and "sitelink.js" are not the same file on a Unix web server and you will have some challenges to get your function to load correctly if you don't pay attention to the case of the file names.

 

Additional Revisions, Changes and Improvements

Revision 1 - The Test web server should report the dynamic IP address on a regular schedule.
We determined that once an hour to have this updated would be acceptable, but as we were not interested in writing a timeclock function in PERL (or anything else for that matter), we used the Scheduling function available in Windows to access the CGI script once an hour. On the UNIX box, we used the built-in CRON function to do the same thing. Why reinvent the wheel?

Revision 2 - There should be some sort of authorization in place to prevent hijacking of the link.
We will rewrite the PERL script to accept a QUERY_STRING (another environment variable) and use that as a check for autorization to use this script. We will also quit using the GET call as it is not very secure (cleartext)

Revision 3 - Can this be altered to allow multiple dynamic links?
With the inclusion of the QUERY_STRING variable, it is possible for more than one computer to identify themselves as they access the script. Once they identify themselves, the JavaScript file is written under another name for that specific test server and it is then called from the index page in the normal fashion.

Question - What happens if the test server is offline or does not update?
The link to the test server does not work, seems simple enough. Even if the Javascript file does not load (in this case because it does not exist), it will not affect the rest of the page loading or running, the link will not work and you will get a JavaScript error notice (which most people ignore). You can see the example here.
Call JavaScript Function DYN_DNS.JS

Question - What happens if the dynamic IP address changes after the last update?
The link to the test server will not work until after the test server updates it. If your dynamic IP address regularly changes more than once an hour, then set your CRON function to do the update process more often than once an hour. The once an hour updates we have found are a reasonable compromise between test server link up time and stupid amounts of traffic from too many updates.

Revision 1 -

Revision 1 -

 

Web Links and References

These are some of the links and reference sites we are using while we build this service.