My initial issues with using the WebCT and OASIS systems involved my choice of browser. I use Opera which I find highly configurable and fast (I am on dialup), but this is not a supported browser for the Curtin sites.
Internet Explorer 6 (the recommended browser) is, by contrast, much slower, does not have tabs and frequently crashes when trying to save complex frame-based pages (such as those used by WebCT and OASIS).
Nonetheless, it appears both systems work perfectly with Opera, and I have been using this browser without any problems (apart from the constant popup warnings about my choice of browser).
It’s been a long time since I last used telnet, but the process itself was straightforward. Telnet has the virtues and disadvantages of most command line interfaces (such as DOS): it is fast, but every system tends to have a different method of navigation.
The Deakin Library access was very efficient at locating the desired records, and forwarding that information on via email, giving the following results:
From DEAKIN UNI LIB
Sent Wednesday, November 28, 2007 11:02 am
Subject Email from DEAKIN UNI LIB
You searched for the AUTHOR: bennahum
2 AUTHORS found, with 2 entries; AUTHORS 1-2 are:
1 Bennahum David A 1936 …………………………… 1 entry
2 Bennahum Ninotchka ……………………………… 1 entry
The FTP task was also relatively straightforward since I have maintained a number of websites (requiring the regular use of FTP), and FTP is effectively the same as using Windows Explorer, or other file managers, but across a network connection. The only issue was locating the relevant README file since it was not in the root folder. The readme.txt file located in the MSC subdirectory provides the following caution:
This server runs on a unix platform, so CAPITALIZATION MATTERS!
This task required using a website to trace the internet hops to curtin.edu.au. I used network-tools.com, giving the following steps:
188.8.131.52 is from Australia(AU) in region Oceana
TraceRoute to 184.108.40.206 [curtin.edu.au]
Hop (ms) (ms) (ms) IP Address Host name
1 0 1 1 220.127.116.11 gphou-66-98-244-1.ev1servers.net
2 7 0 0 18.104.22.168 gphou-66-98-241-13.ev1servers.net
3 0 0 0 22.214.171.124 gphou-66-98-240-5.ev1servers.net
4 1 1 1 126.96.36.199 ge-1-14.r04.hstntx01.us.bb.gin.ntt.net
5 1 1 1 188.8.131.52 xe-0-1-0.r21.hstntx01.us.bb.gin.ntt.net
6 43 43 43 184.108.40.206 as-1.r21.lsanca03.us.bb.gin.ntt.net
7 43 43 43 220.127.116.11 p16-1-0-0.r02.lsanca03.us.bb.gin.ntt.net
8 201 202 201 18.104.22.168 p4-4-1-0.r02.lsanca03.us.ce.gin.ntt.net
9 198 197 201 22.214.171.124 so-3-2-0.bb1.b.syd.aarnet.net.au
10 213 210 213 126.96.36.199 so-2-0-0.bb1.a.mel.aarnet.net.au
11 222 222 222 188.8.131.52 so-2-0-0.bb1.a.adl.aarnet.net.au
12 249 246 246 184.108.40.206 so-0-1-0.bb1.a.per.aarnet.net.au
13 250 250 246 220.127.116.11 gigabitethernet0.er1.curtin.cpe.aarnet.net.au
14 250 250 249 18.104.22.168 gw1.er1.curtin.cpe.aarnet.net.au
15 246 250 250 22.214.171.124 –
16 246 250 249 126.96.36.199 te1-1.b309-sr.net.curtin.edu.au
17 246 246 246 188.8.131.52 –
Seventeen hops were required to the Curtin site (the IP number for which is 184.108.40.206) The average time for these hops was 246 milliseconds (which is similar to the time of 252 milliseconds recorded when I performed the same test via centralops.net/co).
Pinging the webct.curtin.edu.au site produced the following result:
Pinging webct.curtin.edu.au [220.127.116.11] with 32 bytes of data:
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Ping statistics for 18.104.22.168:
Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),
Pinging from network-tools.com produced a similar result, which would indicate that the WebCT site is the cause of the problem:
Average time over 10 pings: 0 ms
In my experience, difficulty reaching a site is usually a result of the site being down, or the connection being unavailable for other reasons, but pinging the site at other times consistently produced the same result. The Microsoft help page for this error recommends pinging the local loopback address (127.0.0.1) to ensure the ping command is functioning at the local level. This worked, as did pinging the local ISP and curtin.edu.au, which would seem to indicate that the webct.curtin.edu.au address is unresponsive to ping requests.
According to Testing Your Network Connection:
Some ISPs block access to one or both of these commands [ping and tracert] so a failed result from either of these commands does not necessarily mean that their communication link is down but if both of these commands and your application (web server, ftp program or whatever) all fail to connect then chances are that their system is down.
Since my browser was communicating with the Webct site at the time, it would appear that the ping command is deliberately blocked. The tracert command, however, did work, and gave the following output:
Tracing route to curtin.edu.au [22.214.171.124]over a maximum of 30 hops:
1 386 ms 458 ms 392 ms 220-245-178-161.tpgi.com.au [126.96.36.199]
2 397 ms 537 ms 392 ms syd-nxg-ibo-iri-1-vlan-1.tpgi.com.au [188.8.131.52]
3 527 ms 393 ms 512 ms syd-nxg-ibo-zeu-1-port-channel-1.tpgi.com.au [184.108.40.206]
4 391 ms 458 ms 392 ms syd-pow-ibo-zeu-1-po-11-2.tpgi.com.au [220.127.116.11]
5 527 ms 392 ms 721 ms 18.104.22.168
6 603 ms 550 ms 904 ms nsydnbrdr01-ge4011.powertel.net.au [22.214.171.124]
7 564 ms 392 ms 734 ms gigabitethernet2-0-1.pe1.c.syd.aarnet.net.au [126.96.36.199]
8 389 ms 511 ms 392 ms ge-1-0-5.bb1.b.syd.aarnet.net.au [188.8.131.52]
9 501 ms * * so-2-0-0.bb1.a.mel.aarnet.net.au [184.108.40.206]
10 468 ms 419 ms 471 ms so-2-0-0.bb1.a.adl.aarnet.net.au [220.127.116.11]
11 573 ms 444 ms 445 ms so-0-1-0.bb1.a.per.aarnet.net.au [18.104.22.168]
12 425 ms 431 ms 419 ms gigabitethernet0.er1.curtin.cpe.aarnet.net.au [22.214.171.124]
13 423 ms 419 ms 786 ms gw1.er1.curtin.cpe.aarnet.net.au [126.96.36.199]
14 485 ms 576 ms 1285 ms 188.8.131.52
15 628 ms 445 ms 458 ms te1-1.b309-sr.net.curtin.edu.au [184.108.40.206]
16 458 ms 668 ms 458 ms 220.127.116.11
The number of hops was only one less, though the average time was over double, the previous traceroute. This is counterintuitive, especially being in Perth, since the physical distance between the two computers is much less than between the US server and Curtin. Nonetheless, it is sobering to realise that physical distance means less on the internet than the number of connections (which, in this case, go from a local computer to an ISP, then to an internet backbone, and eventually to the required Curtin server in both cases).