I then used 3d Traceroute to check the number of hops, to find they had dropped down to 15 from the earlier task’s 19-20. The largest difference (and surprise) was the time taken for the trace – an average 0.615 seconds per trip. So while the number of hops had dropped by approximately 25%, the average times had nosedived by roughly 80%. Another thing I found was that in the other traceroute tests, once the packets hit Australia they were routed via Sydney-Melbourne-Adelaide-Perth through AARNET’s routers, yet testing from my computer it didn’t hit AARNET until the 9^th hop, being carried until then by Optusnet. The address on the 9^th hop was strange though, almost as if hinting at a router’s ownership shared between 2 domains – AARNET.o6ssc76fe.optus.net.au. It appeared immediately before Perth’s hops began, and after the address 61.88.226.121. The last Optusnet hop ended with the first two octets of that address, so perhaps that is the Australian backbone address? There were no addresses beginning with the octets 61.88 in the other traceroute tests though, so I doubt it. I know you can’t surf to it, already tried…well, should I say surf to it using http, there’s probably other ways to get there using other protocols. Interesting that 61 is the telephone country code for Australia, so a funny coincidence that it happens to be the first octet in a telephone provider’s IP.

I wasn’t surprised by this result as in all travel, distance will affect time. From my computer to the WebCT server, the PING has to travel from my computer to my ISP, get routed through regional and national ISP’s and then arrive at WebCT. From fifi.org however, it is coming from an international destination so not only does it have to go through regional and national servers, but has to join a world ISP to be routed through an international backbone before once again hitting national and regional servers again. I believe the process of having to travel through what I’ll term “high-traffic gateways” (meaning those first/last routers as you enter/leave a country or region) twice each trip, is what adds the extra time. Of course time will increase with distance since light travels at one speed and most of the high end cabling is fibre-optic.

To test out my theory on the “high-traffic gateways” affecting time I held a little experiment. I worked out the distances (as the crow flies) between Sydney and both Perth and Auckland, Perth being roughly 3300km away and Auckland around 2150. I chose Auckland because for the purpose of the experiment I needed a large city overseas with technology on a par with Australia, yet the city must be either the same distance away or less from my computer. From the previous PING test we know it takes approximately 66ms for a PING from my computer to Curtin, so it was time to PING a site based in Auckland, the Auckland University of Technology (www.aut.ac.nz). Over a series of 10 PINGs I got an average time of 32ms.

So now it’s back to the drawing board after I post this, as the results didn’t match what I thought. If the PING result was based on straight distance then the Auckland PING should have been around 2/3 of the Perth PING time, not under half. My theory about traveling through international routers and having to re-enter regional areas slowing the PING down also seems flawed with a 32ms PING to Auckland. I’ll have to research the actual network nodes and router points between each site to do the test properly, and map the connecting route taken, but that’s for another time.

An interesting and fun task all up, taking much longer than I originally planned for a task based around the simple PING command, lol. In my travels I also found the original author of PING’s site (http://ftp.arl.army.mil/~mike/), worth a visit with some interesting information on other programs and code, including a funny review of a children’s book that was mistaken for the description of PING (http://ftp.arl.army.mil/~mike/ping.html). Read the review and see what you think, could it actually be used as a story describing PING?

Tracing route to curtin.edu.au [134.7.179.53]…

Trace complete

This told me there were 19 hops before reaching Curtin (20 in total), and that the average time for the trip was just under 2.4 seconds. It also showed the IP address of the hostname curtin.edu.au to be 134.7.179.53. I then went to the second suggested site, network-tools.com and did the same exercise again with the following results:

134.7.179.53 is from Australia(AU) in region Oceana

TraceRoute to 134.7.179.53 [curtin.edu.au]

Trace complete

This time there were only 19 hops in total, yet the average time for the trip had increased to just over 2.6 seconds. They reported the same IP address for Curtin but also gave the added information that the address being traced is in Australia in the region of Oceana.

It was here that I realised a lot of this unit so far gave you the option of what I’ll term ‘Cut & Paste learning’. In this I mean if you go through the module and follow the suggestions given for the software, the pages etc you will be able to get the answers needed to complete the tasks, but are you really giving to the subject? Sure you’ll walk away with a passing grade but you won’t really have got the most that this unit offers, or necessarily have the skills or information to complete any of the set tasks in real life. Sure you’ll know that both centralops.net and network-tools.com allow you to Traceroute or ping a server, but what if those sites disappear? Without actively seeking out other sources of the same information, and trying different programs than those suggested in other tasks are we really taking in the information being taught? Have we truly learnt the subject matter? So I decided to have a surf and see how many other sites there were out there with the same tools, and pick one to redo the task. There were many more sites offering the same service than I thought there would be, and trying the exercise on a few of them found the time always varied but stayed between 2.3 – 2.6 seconds, and the amount of hops ranged from 16 to 20. I found it interesting that in all the tests, you could see how the time increased dramatically around halfway along the journey. After reading the concepts and the links to How Stuff Works (http://computer.howstuffworks.com/web-server3.htm) I surmised it to be at a point in the journey where the information had passed out of the local domain and through both the regional and world ISP’s, and had come to the traffic of the regional ISP of the Traceroute target’s domain.

I can see the value of Traceroute as an educational tool, but can also see the application of it in network maintenance and the future development of the internet. For network administrators it seems a great little tool to track where you may have network bottlenecks, even on company LAN’s. Because each hop gives the address of the router, you can see where on the network information is getting held up and then troubleshoot that particular router and the computers directly connected to it. On the benefits it could give to the development side of the internet, I believe it could spur on the search for better and faster routers, better performing or higher bandwidth cabling. Perhaps it might even go further and inspire someone to develop a totally new network protocol to transfer information at a faster and more stable rate. Because it shows the time that each hop takes, as well as the number of hops to a given destination, it could also be used by internet game developers and other business models to test the viability of new marketplaces.

For example you have developed a game to be played online, but it’s very graphics and music intensive and relies on quick decisions and reactions to play the game successfully. You’ve tested it on multiple network configurations and worked out that a PING of around 2 seconds is the most that is acceptable to play the game. Using Traceroute you could test how many hops and how much time it takes from your central game server to different domains around the world,  finding out if your game could be played from there, or whether you need to set up another local server in that country to enhance game quality.

 

It did make me wonder though, if in this task capitalization matters, then why was the file called README and not readme in the task instructions? Was it just a thought that everyone would do as I had originally done, and assume that the target was readme.txt? Or is this in fact a trick question in which the correct answer is – there is no missing word as the file README does not exist on the server recall.curtin.edu.au?

Overall my thoughts on this task are that I cannot see at this point in time FTP being replaced, as it is a simple and easy method of transferring files between computers over a network, especially larger files such as programs, music and movies. You use a client such as Filezilla to access an FTP server, and when you receive the file you chose to download it is ready to use. I remember when to transfer files you had to use a program called a uudecoder to get files from BBS’s. If you opened a file after downloading it looked like a meaningles jumble of text characters that made no sense at all. But once you converted the file back to it’s original state using the uudecoder, you could view the graphic or use the program as it was intended.