INTRODUCTION
The Growth Of The Internet
In 1969 the Advanced Research Projects Agency Network (ARPANET) was commissioned by the United States’ Department of Defence (DoD) for research into the networking of computers. Four network nodes were constructed. They communicated using the first host-to-host protocol NCP (Network Control Protocol). By 1971 there were 15 nodes on the network with 23 hosts between them (Zakon, URL).
In 1982 the Defence Informations Systems Agency and ARPA established the Transport Control Protocol/Internet Protocol (TCP/IP) suite of applications as the standard for ARPANET. This led to one of the first definitions of “an internet" as a connected set of networks, specifically those using TCP/IP, and "the Internet" as connected TCP/IP internets. The DoD declared the TCP/IP suite to be the standard for all DoD networking.
Table 1 The growth of the Internet
(Source: Zakon Internet Timeline)
In 1991 there were over 100,000 hosts on the Internetwork. The World Wide Web (WWW, W3, “the Web”) was released by the Conseil Europeen pour la Recherche Nucleaire (CERN). The WWW is an interconnected system of linked documents residing on servers worldwide.
In January 1999 Zakon estimated that there were some 43,230,000 hosts on the Internet. If the rate of growth remains unchanged there could be 100,000,000 hosts on the Internet by the end of the year 2000.
Internet Use
Services which run over the Internet are often known by the protocols which define them. A file server is known as a File Transfer Protocol (FTP) server. A Web server is a Hyper Text Transfer Protocol (HTTP) server. The Internet can host other services known by their proprietary names. A Quake[1] server is one example. Search facilities which access server-side databases are another. Since they are all on the Internet they must all use IP addressing to specify their location.
· SMTP Protocol
The Simple Mail Transfer Protocol (SMTP) is one of the earliest protocols. It is used to send and receive email. The protocol consists of many commands. A mail server will respond to the “HELO” command by replying “HELO” and appending the IP address of the client which sent the command.
· FTP Protocol
The FTP Protocol is used to transfer files from one location to another.
· HTTP Protocol
HTTP is used to make and maintain connections between servers, allowing the exchange of hypertext documents. HTTP capitalises on the fact that navigation information can be embedded in such documents directly.
· IRC Protocol
This protocol allows multiple users across an Internet to share a common interface. An Internet Relay Chat (IRC) server can also be commanded to return the IP address of the client.
Growth Of The World-Wide Web
Table 2 shows how the growth of the WWW has mirrored the growth of the Internet (See also Table 1).
Table 2 Growth of the World Wide Web
(Source: Zakon Internet Timeline)
The Web can be used for many purposes. The public sector can use it to increase public awareness of their activities and to make their services more accessible. The commercial/corporate sector is making increasing use of it to promote their businesses and conduct online transactions. Large-scale commercial enterprises like Tesco (tesco.net) and the Dixon’s Group (freeserve.com) are now becoming free-of-charge Internet Service Providers (ISPs). They are able to promote their ISP status in-store and their core businesses online. The Daily Sun (News International Corp.) offers free Web hosting to its readers at www.currantbun.com. The net result is that Internet traffic is increasing rapidly.
|
World Total |
55 million |
|
Canada &
USA |
90.63 million |
|
Europe |
40.09 million |
|
Asia/Pacific
|
26.97 million |
|
|
|
Table 3 Population online.
(Source: www.statmarket.com)
It is currently estimated that as many as 55,000,000 people are online by one reckoning (Table 3[2]), 205,000,000 by another (Table 4). The art of estimating how many are online throughout the world is an inexact one at best. Surveys abound, using all sorts of measurement parameters.
Table 4 How many online world-wide.
(Source: www.nua.net)
Internet Protocol Addressing
The availability of IP addresses is crucial to the expansion of the Web. Each Internet host must be assigned a unique address so that packets of information can be delivered to it.
A 32-bit positive integer is used for each IP address. There are two of these addresses associated with each host attached to any internet. In the terminology of the International Standards Agency (ISO) these are the Network Service Access Point and the Subnet Point of Attachment. With the TCP/IP suite of Internet protocols these are the IP address and the Network Point of Attachment (NPA) respectively. The NPA address is different for each network/subnet type, whereas the IP address is the unique internet-wide identifier (Halsall, 1996).
This 32-bit integer is transmitted and stored in binary form. The subfield boundaries within each address are located on byte boundaries to simplify decoding. The 32 bits are broken into four bytes and converted into their decimal form with a dot between each. This is known as a dotted decimal or dotted quad. As an example, the IP address 01111110 01000100 01111100 10001000 is represented as 126.68.124.136.
The central authority for the Internet is the Network Information Center (NIC) who are responsible for allocating IP addresses. ARPANET defined more than one type of IP address in order to give the authority some flexibility. The three main address formats are called Class A, Class B and Class C[3]. These addresses are identified by having the leading bits of their respective 32-bit numbers set to 0, 10 and 110 respectively. The remaining bits specify two subfields - a network identifier (netid) and a host identifier (hostid). This allows for networks of differing configuration.
· Class A
The 0 and subsequent 7 bits are used for the netid. This leaves 24 bits for use as the host id, so each host can directly address up to 255.255.252 (16,386,300) clients[4]. Networks like ARPANET and the Massachusetts Institute of Technology (MIT) network use Class A addressing.
· Class B
The first two bytes comprise the netid and the second two bytes the hostid. These addresses are commonly allocated to educational servers (.edu domains), ISPs and other networks of a similar configuration.
· Class C
Class C addresses are commonly allocated for general use on the Internet by the NIC.
Each application program running on a server has a port number assigned to it. The number is used to link the incoming data to the correct service. By default port 80 is used for HTTP traffic, port 21 for FTP traffic and port 25 for SMTP traffic. If a non-default port is being sought by a client wishing to connect a colon followed by the port number is appended to the IP address.
Uniform Resource Locators
Uniform Resource Locators (URLs) are used to specify an exact file on the Internet. It is a complete address containing the protocol to be used for the transfer, the address of the machine on which the file resides (the IP address including a port number if required), the path to the file on that machine and the name of the file (Castro, 1999).
Example: [http://][192.73.73.121][\pub][\index.html]
Domain Name Servers
In 1984 the Domain Name Server (DNS) system was introduced. It is supported by many volunteer servers worldwide which maintain a regularly updated table of domain names which are aliases to dotted quad IP addresses. This system substitutes a name in place of the dotted quad IP address when contacting a server on the internet. A server may be contacted by using either the IP address or the domain name:
ftp>open
194.168.18.138 / ftp>open ftp.btinternet.com
For HTTP servers on a non-standard port:
http://192.73.73.121:8080
/ http://www.btinternet.com:8080
The IP addressing system has not changed since it was introduced. Clearly there are a finite number of addresses available. In 2006 a new system of addressing should be in place which increases the address space from 32 to 128 (Carpenter, URL). In the meantime the rapid growth of the WWW is inevitably putting the system under pressure.
Internet Service Provision
Internet Service Providers are the public’s access points to the Internet. The ISP maintains a permanent connection to the Internet. There are a variety of ways to connect to an ISP. The most common domestic access method is by modem using telephone dial-up access. (See Telecommunications).
IP addresses are allocated to ISPs in blocks and there is no set protocol concerning their subsequent use.
· Static IP Addressing
The ISP may allocate a single fixed IP address to each of their customers. This address will remain unchanged for as long as the customer maintains the account.
·
Dynamic IP Addressing
Other ISPs use a system of Network Address Translation (NAT) which allows more machines to be connected than the given number of IP addresses. The NAT system maintains a pool of addresses which are allocated dynamically as connections to the main server are made. The assumption is made that not everyone will be connected at once allowing a few hundred addresses to be shared between several hundred users.
Within a network of this type only the NPA (internal LAN) address is visible to each node. The NAT also works as a proxy server in that when a machine requests a file from an address outside the LAN it is fetched by NAT using a dynamically-allocated IP address and delivers it to the requesting machine at its NPA address. The requesting machine therefore does not know the details of its external IP address.
Hosting Services
In theory any computer connected to the Internet can host its own services. Running a server while connected to the Internet allows the host machine to provide Internet services directly to the Internet community. This goes beyond using the Web space provided by an ISP to build a Web site. As part of their service ISPs make 10Mb (typically[5]) of space available on their servers to each customer so that they can develop their own Web-site. A Web site is an Internet service; Hypertext documents (Web-pages) can also act as the interface to other Internet services besides HTTP, for instance a database search facility. In such cases the Web pages should not be confused with the services themselves.
ISPs place severe restrictions on which, if any, server-side applications may be run on their Web servers due to serious technical and security issues. Some ISPs allow 3rd party Common Gateway Interface (CGI) scripts[6] to be run by special arrangement. If domestic users want to provide Internet services of their own they cannot do so by utilising the Web space provided by their ISP. In addition the telecommunications technology available to domestic users has, until very recently, been unsuitable for this purpose.
Telecommunications
Governmental, academic and large corporate networks are able to maintain permanent high-bandwidth telecommunication links with the Internet. For domestic PC users wishing to connect there have until recently been two methods available, by data/fax modem and ISDN. As a response to the increasing demand for high-bandwidth Internet access new technology is being delivered which will eventually supercede these methods.
Dial-Up Technology
The latest fax/modems transfer data at speeds of up to 55.6Kbps. This data stream is one-way and the frequent interruptions required to send a confirmation packet back upstream often results in a lower mean. In the UK call charges are structured such that maintaining a connection of this bandwidth in this manner cannot be considered viable. ISDN can transfer data at up to 128 Kbps (although most ISPs only provide 64 Kbps access). This makes it more useful for transferring files and other applications because it is faster. The cost of installing the equipment varies but a typical price is £500 plus £100 per month (Demon Internet, URL), plus call charges.
Permanent Connection
Two-way broadband telecommunications technology is now becoming available in Britain on a wide scale at much lower overall cost. This offers domestic users a relatively high-speed affordable permanent Internet link.
NTL HiSpeed Internet have made available (April 1999) a fiber-optic cable solution delivering data at speeds of up to 512Kbps. The cost of the equipment is £149.99 and there is a flat rate charge of £40 per month. This provides a permanent Internet connection. The system uses dynamically allocated IP addresses (NTL.com, URL). Cable And Wireless Communications are preparing to offer a comparable service beginning in September also using fiber-optic cable technology (Cable And Wireless Communications, URL). This system will also use dynamically allocated IP addresses.
Solutions such as British Telecom’s (BT) Asynchronous Digital Subscriber Line[7] (ADSL) implementation utilise copper wire as a transmission medium. ADSL was developed to be deployed using existing telephone lines. Within 3 miles of a telephone exchange ADSL can achieve downstream speeds of 2 Mbits per second, four times faster than cable and a minimum of 16 times faster than ISDN (60x faster than a 33.6K modem). Installation costs have yet to be announced. The service is currently being offered as a trial at £30 per month. The Financial Mail Online (Financial Mail Online, URL) reports that “BT intend to roll out their ADSL technology to the public this Autumn…beating the cable providers to market in the many areas of the country which are not accessible by cable”.
These new technologies create the opportunity for domestic users to provide their own Internet services. The connection is permanent: There are no call charges. The bandwidth offered is such that data transfer speeds will be relatively high. The use of dynamic IP addressing within these new networks makes hosting services technically challenging since the Internet address of each node is subject to constant change.
BACKGROUND RESEARCH
Introduction
It would appear that a driving force behind the expansion of the Internet and the Web is commercial interest in new markets. The technology which has given the domestic user permanent broadband access to the Internet blocks the ability to host Internet services due to the use of NAT. I took the opportunity to subscribe to the BTi ADSL trial in late 1998. Far from wanting another way to shop my intention was to use my permanent connection to transfer files between home and University. I conducted an online survey of other subscribers to the trial to discover if others had similar needs. Based on their responses and the solutions they have already found to some of their problems I have designed software which will enable users connected to the Internet with a dynamically allocated IP address to host Internet services.
The BTInteractive ADSL Trial
BT’s BTInteractive (BTi) group are responsible for conducting a domestic trial of ADSL in the North and West London areas. There are 900 subscribers to the trial. BTi are using NAT to administer 254 IP addresses between them. NAT will be used when the system is rolled-out nationally in the Autumn[8].
Survey Of Subscribers
To discover whether domestic users were using ADSL to host their own services an online survey was conducted of contributors to the btinternet.support.beta newsgroup. Of the 900 people on the trial approximately 97 contribute to the newsgroup. It is not known exactly how many of the 900 subscribers know of the newsgroup as BT do not officially advertise its existence to subscribers. It is not therefore safe to assume that the contributors are typical of all subscribers. In my opinion they have shown themselves to be particularly pro-active by finding the newsgroup. The newsgroup was asked the following questions:
|
1) Have you run a server during this trial? |
|
2) If so, have you encountered any problems? |
|
3) What is the nature of problem/s? |
|
4) What solution/s did you find the problem/s? |
|
5) What kind of services do you provide? |
|
6) Any further problems since finding your solution (if applicable)? |
|
7) What services if any are you still prevented from providing? |
|
8) What Operating System do you use? |
|
9) Which of the following most accurately describe your use of ADSL? · Domestic/leisure/entertainment · Commercial · Academic |
Results Of Survey
See Appendix A for a full table of results.
Summary Of Results
The replies I received show:
|
1) Of those who replied all have run servers with varying degrees of success. |
|
2) Three distinct problems have been identified. |
|
3) These problems all relate to dynamic IP addressing. |
|
4) Two similar commercial solutions and one [experimental] solution have been found. None are regarded as ideal. |
|
5) The main interest is in running FTP, HTTP and games servers. |
|
6) In most cases lack of automation requires the presence of an operator at the host. |
|
7) FTP, HTTP and games servers are difficult to run over the Internet despite the above solutions. |
|
8) Win95, WinNT, UNIX and LINUX are all used by subscribers. |
|
9) Academic, commercial and domestic solutions are all being sought. |
Discussion Of Results
From the results of the survey it can be seen that there is an identified need to make a range of services available across the Internet, typically between home and work or University via HTTP and FTP. The main problem is that of not knowing one’s home IP address so that when one is at a remote location a connection cannot be made. A workaround to this is included in the EZ-IP package (see below) but it only works with one out of the variety of Operating Systems in use by the subscribers. The method of notifying others by email of the correct IP address is effective but requires the presence of a system operator. This is not a problem for those hosting games as they do so from the host machine, not a remote location. In my opinion it would be of benefit to them to have this procedure run automatically.
In BTi’s ADSL implementation 900 users are sharing 254 IP addresses. The NAT will de-allocate an address which has not been actively used for a set period of time (the timeout period) for example in-between or even during ftp transactions or whenever the computer is rebooted. Also the pool of IP addresses can become exhausted resulting in a period of disconnection until a new address becomes available (BTi Technical, URL), the only solution to which is to reduce the ratio of users to IP addresses.
The problem of time-outs and re-allocation of IP addresses cannot be addressed by 3rd-party software. The short timeout problem was addressed by BTI during the course of writing this report. Mid-session disconnections increase in inverse proportion to the timeout period resulting in poor service and customer complaints. As a result, the time period over which an IP address remains allocated by NAT between instances of network activity by the host computer has been increased. Mid-session disconnections are rarer. The problem remains that IP addresses are subject to change as this is a core function of the NAT system.
Two solutions to the problem of not knowing one’s IP address have been found by the subscribers; remote hosting services and IRC server querying. The first involves the use of remote hosting services[9] such as those provided by EZ-IP.com and TZO.com. The hosting service allocates a permanent hostname to the client through which it can be contacted. Traffic wishing to connect use this address in the usual way. The hostname is resolved by any of the main Internet DNS servers to an address at the hosting service’s network. From here the hosting service’s own DNS server redirects the traffic to the client’s machine.
This system has the disadvantage that the hosting services’ DNS database must be updated every time the client’s IP address changes. This might be once a day or more frequently. EZ-IP have very recently (April 1999) made available a small program which updates their DNS server automatically but it only runs on the Windows platform. Other remote hosting service providers require the database to be updated manually. These are commercial solutions which must be paid for. The cost of services vary with the level of service and £50 per month is not uncommon for entry-level service. Anecdotal evidence suggests this is to expensive for those in the domestic/leisure/entertainment usage category above.
The second solution involves the use contacting an IRC server. An IRC service will return the IP address of any machine that commands it to do so. This IP address can then be communicated to interested parties with an invitation to connect. The advantage is that this is free and can be done by anyone who understands the protocol. However it is a manual procedure requiring the user to start up an IRC client, connect to a server and issue the appropriate command to obtain their current IP address. This must then be advertised to interested parties in some way. Regular manual checks must be made to ensure the IP address being advertised is correct.
Conclusion
A small proportion of subscribers to the trial ADSL service from BTi wish to host Internet services. They have difficulty in doing so due to the use of dynamic IP addressing. At present there are two solutions available but in the view of the subscribers none of these solutions is ideal. In the main both solutions require manual operations to be carried out requiring the presence of an operator at the host machine. The one remote hosting service to offer a layer of automation (EZ-IP) only does so for the Windows platform. This is not suitable for all subscribers as they are employing a mix of Operating Systems.
SYSTEM IMPLEMENTATION
System Design
General Considerations
In terms of cost to the end user any software must represent good value in the light of current solutions. It must be simple to operate and robust enough to withstand network outages (Curtis, 1998). In this case due to the variety of operating systems in use it should operate cross-platform. Most importantly it must solve the problem of making a connection to a dynamic Internet address. Finally it must be distributed to those who may find it useful.
The aim of this project therefore is to build a system which
· works on the hardware and software level
· has an interface that conforms to principles of Human-Computer Interaction (HCI)
· fulfils the system requirements
· is acceptable to users.
System Requirements
The system is required to make a link to a dynamic IP address. This is to meet the need of two groups; those operating game servers from home and those wishing to connect to their machines from a remote location. This link can be in the form of a URL which will transfer a Web browser to the correct address and in textual form for copying into other applications.
Figure 1 is a top-level diagram of the proposed system in action. Subscriber’s machines are connected to the Internet by the NAT server using a temporary IP address. The System obtains the address from another server on the Internet outside its own network. This is published on the WWW in the form of a Web page. This page informs visitors of the subscriber’s IP address and redirects Web browsers to the server at that address.
To implement the system, the software will be required to:
1) Collect some data from the user.
2) Obtain the host computer’s external IP address.
3) Make this address available in a form which will allow other users to connect to the host computer’s server via the Internet.
4) Regularly check the IP address and update files accordingly.
Implementing System Requirements
1) Implementing a Graphical User Interface (GUI) can increase usability and clarify the operation of the system to the user (Dix et al., 1998). The GUI should exploit its abilities to prompt for information, display default system settings and show the current system settings. It must be easy to read and the labels unambiguous.
2) As an aid to usability the details entered by the user should persist across sessions so that they do not need to be repeatedly re-entered. These details (the “user profile”) should be stored and displayed during the current execution of the application. They should also be written to file for use after a system re-start.
3) To obtain the current IP address a mail server can be commanded to return the system’s current IP address. The user should be informed of the current IP address and notified of any change. The returned address can be stored and responded to appropriately.
4) An HTML file can then be written to disk with the current IP address forming part of the URL embedded in a redirect tag[10] or clickable hyperlink.
5) This HTML should be uploaded to the user’s web-site making it publicly available.
6) A timer can be incorporated into the application which periodically runs that part of the program which obtains the IP address. Subsequently the IP address can be compared to the previous address returned and appropriate action taken.
7) The progress of the program should be completely automatic once initialised so that an operator need not subsequently be in attendance.
8) The program should be written in JavaTM to provide cross-platform compatibility.
Software Design
To fulfill the requirements certain information is needed by the application. Data acquisition must be synchronised so that events may proceed in logical sequence.
· The name of a mail server.
· The name of the html file to be written.
· The port number of the prospective host’s server.
· The time delay for the HTML redirect.
· The name of the FTP server used to upload pages to the regular web-site provided by the ISP.
· The FTP username.
· The FTP password.
· A filename for the user profile.
· The time delay required between program cycles.
Some input validation should be performed to ensure that correct values are entered and feedback provided to the user to assist fault-finding.
System flowcharts were produced to model the behaviour of the system at runtime. These charts give an overall picture of how each part of the system will interact with the whole. (See Appendix B).
Program Development
An iterative approach was adopted. The following is not a strict time-line account of the development but accurately reflects the iterative process. A general structure for the program was “sketched out” using dummy functions. System.out.println statements were used to check flow and continuity. The variables were initialised to default settings and the functionality of each method developed (Appendix C). Sketches were made of layouts for the main GUI dialog (named “Configuration Details” Figure 1) with the required fields grouped in various ways until a layout was decided upon which appeared to present the details in a logical manner.
It was felt that using the main GUI to display the current IP address would make the interface unnecessarily cluttered and waste screen real-estate as the components were already numerous. The original decision to include fields for all the required parameters on one interface was made to prevent the user from having to deal with a tiresome series of dialogs (Preece et al., 1997). A second much smaller GUI (named Control Panel - see Figure 2.) was developed to provide the required feedback and to display the current cycle interval of the program. The two GUIs were made mutually exclusive, the Configuration Details dialog being dismissed on pressing “Done” until needed again. A button was provided on the Control Panel to recall it again as necessary.
The Configuration Details GUI is a subclass of a dialog object and is set to modal. This has the effect of suspending the system until the dialog is dismissed. The program takes no action until the “Done” button is pressed.
Several write-to-file operations take place during one complete cycle. A read/write-to-file class (named FileAction.class) was developed from the existing methods to handle all file Input/Output (IO). Failures are detected by setting all FileAction methods to throw a programmer-defined Exception which must be caught whenever called by the main application. All IO errors are handled gracefully by this method and as a result the program should be less prone to failure.
GetMyIP.class was developed separately to handle the task of obtaining the IP address from a mail server. This requires data streams to be written and read over the Internet which could destabilise the main application. Programmer-defined Exceptions were again used to make any failures graceful. The class returns an IP address or null to the main application where all decisions on how to proceed are made.
The program writes an HTML file to disk using a FileAction object. The current IP address forms part of the URL which defines the inbuilt links. A configurable redirect tag is embedded in the <head> of the document. A clickable hyperlink displaying the current IP address is shown in the <body>. The page conforms to HTML3.2 standard.
This programmer’s original intention was to create a thin FTP client object which, given the appropriate information by the application, would upload the file to the server by reading and writing FTP commands. This proved to be problematic. There are several forms of FTP in common use supporting different modes of communication. To write an FTP client which would be able to communicate with any FTP server was felt to be beyond the scope of the project and so a separate solution was sought. All of the Operating Systems in use by the intended user group have thin FTP clients built in to them. No GUI is made available; operation is via command-line prompt. The program’s executable binary file will take a filename as an argument. The file consists of a delimited list of commands in ASCII. The FTP program executes these commands in sequence. This entire operation can be “shelled out” to the host OS by obtaining the Runtime Environment from the Java Virtual Machine and making a call to its exec method. This program writes such a file to disk, containing the arguments for the FTP session. It is passed by name as part of the call to the OS shell.
It was decided at this stage to provide the user with the option to not upload the file. The HTML file written by the application is a very basic Web-page (Figure 4.) incorporating a link and a redirect tag. If the user wishes to edit the page to better suit their needs before uploading, or to use the application solely to keep track of their IP address, then the “publish file” option on the System Profile dialog can be unchecked. If this dialog is left checked the program always attempts to upload even if the IP address has not changed. This is to allow the user to change other features of the page such as the redirect delay or filename.
As part of the development process, a working version of the program was given to one of the subscribers to test. The first comment made on receiving the files was “What do I do with it?”. It was at this point that a help file was developed. As it can be very cumbersome to construct lengthy, complicated strings in Java a “readme1st.txt” text file was written. This is displayed on start-up by a third GUI constructed for the purpose. The GUI reads in the contents of readme1st.txt and displays it on-screen.
This has the advantage that the file may also be read by the user straight from the hard disk using their proprietary text reader (Notepad, in the case of Windows) before the application has been run. During testing it was apparent that having this file present itself to the user every time the program is started could become annoying, so an option to not show it on start-up was included on the interface. A button was made available on the Control Panel to show the help window again if desired. The help window is a useful place to also display messages relating to the state of the system (Figure 5). The “Show Help” button was moved onto the help screen and the button on the Control Panel used to simply show the screen.
With the GUIs created and functioning as intended further testing took place. The initialisation file was corrupted by truncating its contents, by increasing the length of its list and by removing it completely. The program was repeatedly re-started to ensure that recovery would always take place. Invalid arguments were entered into number fields and text fields to test validation procedures and the code modified accordingly. The operation of the “Save as default” checkbox was confirmed. The HTML file was validated. The development machine was disconnected from the Internet to ensure that the program would take the correct action if no external IP address could be retrieved. The FTP uploading was tested to ensure its operation. It was found at this point that there is no notification from the program if the upload fails (See Figure 3). The code throws an exception if the exec command to the OS shell fails but not if the upload itself fails[11]. Hard-coding a thin FTP client into the program would solve this problem. In this implementation the FTP server name is echoed to screen but not the username and password. It is up to the user to enter correct details.
It was also found that failure to include the “quit” command in the FTP arguments file (ftp.dat) would leave the “shelled” FTP process running in the background. As each new call to the shell starts a new process this would eventually result in an overload of system resources. The code that produces ftp.dat was modified accordingly.
Field Trials
The software was run by three of the ADSL subscribers over the course of several days for a maximum of 60 hours. Cycle times of between 15 minutes and 1 hour were used. Requests for help were referred to the help file which proved to be adequate. There are no formal results but all subscribers report that the system performs as described in the specification. The system was found to be stable and capable of recovering from system restarts and periods of network outage. It can run unattended in the background with no adverse effects. Web page caching was found to be a problem. The site to which the HTML file was uploaded operates a Web cache. This has the effect that uploaded pages may not be seen immediately - when a request is made for the page by a browser the cached version is delivered. Revised HTML was coded in which an expiry date of 1970 was encoded the page. This prevents the Web cache from holding the page. Web caching was also found to be responsible for disabling the redirect tag in some cases. The solution to this was found to be disabling the use of a cache in the Web Browser’s settings dialog. Several suggestion were made by the testers. These are discussed in the following paragraphs.
Discussion Of Software
The program performs as per the specification. It is stable and recovers from error. The initialisation, HTML and FTP-command files are created dynamically; if any of these are missing at start-up the program will still operate correctly. If the host machine’s Internet connection fails the program will write the appropriate HTML file to disk and wait until the next cycle. If a valid IP address is received the HTML file is written, uploaded and behaves as expected.
Shortcomings
There are some shortcomings which could be addressed in future versions. The correct operation of the program is dependant upon the user entering the correct details into the ftp server, username and password fields of the Configuration Details GUI. The program will behave as though all is well even if these details are incorrect. This could mean the system will fail to complete its cycle successfully without flagging the failure. Care must be taken by the user to set the initial configuration correctly before allowing the system to run unattended. The most fail-safe solution would be to hard-code an FTP client into the program; exceptions can then be caught at any point the programmer chooses. The variety of FTP commands accepted by FTP servers worldwide means that this would be a sizeable project in itself. Another solution might be an alert dialog to force explicit confirmation. A third solution would be more rigorous validation of input. For testing purposes I feel it is sufficient that, with the configuration initialised correctly, the system performs as expected. The above holds true for the mailserver name but no IP address will be returned from an invalid mail server; the failure of the system should be readily apparent from the contents of the Control Panel’s IP Address field and from the System Output screen.
At present the program always uploads the HTML file if the relevant option box is checked. If no details have changed since the previous upload there is no need for this to occur. A future implementation should include the necessary code to deal with this.
Testing has revealed that the redirect method embedded in the HTML page may not work if the visitor’s browser is connected to the Web via a proxy. This can be disabled by the user in various ways. This program should include literature on this subject to give warning and instruction.
Further Enhancements
Sound could be used to signal system state, particularly when the IP address has changed or been returned null. This would be most useful when the program was running minimised. The Control Panel’s IP address field could be made to change colour if the address changes or flash red under similar circumstances. In my opinion the interfaces are, while clear, rather dull and workmanlike. They could be made a lot more attractive using some of the graphics capabilities of Java. Using sub-classed canvas components and building in animated buttons and text could make a big difference. The help system could be reworked into something more closely resembling the standard Windows system of help-file management. SwingTM components could be used to provide a more familiar or more original look-and-feel to the interface.
Suggestions From Testers
Several suggestions were made by the field testers. One was to provide feedback on the elapsed time. At present there is no way of knowing how long it will be until the program cycles again. If the time interval is reset, the program will take no action until the current wait is completed. It will then continue with the new interval. Long-term testing is necessary to see whether this would provide benefit. If the machine is to be left unattended there is no need for this feature. If for some reason the user is desperate to update their Web-page straight away this can be achieved by closing and re-starting the application, although this is perhaps a somewhat Spartan approach.
Only one set of configuration details is stored persistently by the program. It was felt by the testers that the ability to store alternative “profiles” would be useful for FTP-ing to more than one site and writing alternative HTML filenames. If this facility were provided by linking the application to a database some interesting possibilities arise concerning the GUI. Editable drop-down lists could be used instead of text fields for example. This would create an overhead in ease of installation and perhaps some cross-platform compatibility problems regarding database formats. A more reliable solution might be the development of the existing initialisation file especially if a way can be found to relieve the overhead inherent in holding all the profiles in volatile memory. I feel that one of these approaches should be implemented in any future version.
The suggestion was made that the HTML page should be made available for editing before upload. It is at present a functional item with little aesthetic merit. It would be impractical to simply halt the program until the editing was completed; the next cycle would see the page completely re-written by the program. There is no facility within the system to directly edit the HTML page and to provide this would in my opinion be unnecessarily complex. A better solution would be to enable a link to a user-defined stylesheet and/or JavaScript file. These could add content and formatting to the page without affecting the operation of the system in any way. I think this is an interesting idea and warrants further investigation. Using current HTML this page could be inset in a top-level page using an inline frame[12] (Figure 6).
Figure 6 The dynamic page published within a static page.
This would provide a dynamically-updated area within an otherwise static page which can be safely bookmarked. In this case a more basic page might be appropriate, perhaps consisting of no more than a single line of text. In this scenario it may be best not to have the HTML page perform a redirect. Re-writing the software to make the inclusion of the redirect tag optional would therefore increase the functionality of the system.
PROJECT CONCLUSIONS
Although the demand from subscribers to the BTi ADSL trial to host Internet services is small, the domestic sector is likely to grow rapidly in the next few years due to commercial pressures. Even at this early stage a demand is there to be met. The survey sample was far too small to be indicative of demand across the Internet as a whole. Since the systems which led to this research are only just coming online it might be useful to conduct a similar survey in a year’s time. Interestingly, those subscribers who do run servers do so mostly for the same reasons for which the Internet was first conceived i.e. to make files and applications available between networks, rather than for the reasons for which the technology has been introduced. The pressures driving the development of the Internet to the point where this becomes possible have been largely due to commercial interests. The demand has put pressure on the addressing system. Systems employed to meet the demand deliver high-bandwidth permanent Internet access but enforce a more passive role on subscribers, allowing them to use Internet services but denying them the ability to host services of their own. Commercial solutions to this problem exist but are imperfect as they were not originally developed to meet the needs of those with dynamically updated IP addresses.
The only absolute solution is for everyone to have a static IP address. The introduction of 128-bit IP addressing in 2006 may make this possible. It is also possible that by then dynamic IP addressing will be inextricably embedded in the technology of the day. In any case it is likely that the demand for Internet addresses will continue to grow exponentially. Teledesic is scheduled to come online in 2003[13]. This is a network of 288 low-orbit satellites providing “affordable” broadband Internet access for “businesses, schools and individuals everywhere on the planet” (Teledesic, URL). Access to the system will be via a small rooftop up-link device connected directly to the PC. It would appear from their literature that Internet access is only one of the services they will be offering. This could mean that the network will operate independently of the Internet, in which case it will use its own addressing system. It remains to be seen whether they will adopt a form of Name Address Translation to administer Internet addresses for external use. Of course there is no guarantee that the Internet will expand in line with the aspirations of those driving the expansion.
The software proposed by this project cannot solve the problem of there being too few Internet addresses available. It does solve the problem of hosting Internet services from behind a dynamically-allocated Internet address, albeit with the limitations placed upon it by the network on which the host machine resides. This system may be used in different ways depending on need. Those wishing to host a Web-site can use the auto-direct feature of the HTML file to transfer visitors seamlessly into the site on their home server. An FTP connection to the home machine can be made by copying the address published by the HTML file into one’s FTP client. The HTML page can also be used to advertise the location of game servers or other services. While the system cannot provide seamless connection of services other than HTTP it may be argued that this was not the problem it was intended to solve. Its principal brief was to make the user’s current IP address available to users of the Internet. A wide variety of services may be provided using HTML by embedding JavaTM applets in Web pages although these pages will also need the current IP address embedded in the call to the Applet. There may be wide scope for the development of services such as these but from a commercial point of view I think it is unlikely. In my opinion any commercial enterprise seeking to support mission-critical or e-commerce servers would be better served by a fixed address and domain name.
I have used the system on more than one occasion to allow me to retrieve files from my home computer to my account at University, so from a personal point of view the project is a success. Whether the system stays in regular use by any of the ADSL trialists remains to be seen.
