TECHNICAL REPORT
OF THE
GLOBAL NETWORKING WORKSHOP
**************************************************************
* *
* DRAFT REPORT *
* *
* This report shows that computer networking using Fido is *
* an appropriate, inexpensive and effective form of *
* communication for Africa and possibly other parts of the *
* developing world. *
* *
* This report is relevant to two audiences: development *
* organisations, who understand the difficulties with *
* communications in Africa; and for people well acquainted *
* with computer networking, but not familiar with *
* challenges of communicating in Africa or with Fido *
* technology. *
* *
* This report is being released in draft form for the time *
* being due to financial and time constraints, and the fact *
* that the technology discussed herein is changing rapidly. *
* *
**************************************************************
-------------------------------------------------
| |
| This report was prepared by Arni Mikelsons, |
| from reports written for the Global Networking |
| Workshop, discussions at the workshop and |
| communication after the workshop. Special |
| thanks to Mike Jensen, Karen Banks, Viv Kendon, |
| Lishan Adam, Doug Rigby, Moussa Fall, Mark |
| Bennett, Kirk Roberts, Maureen James, Rob |
| Janes, Rob Ellis, and David Renzetti. |
| |
-------------------------------------------------
(c) Nirv Centre, April 1992
Table of Contents
PREFACE
INTRODUCTION
OVERVIEW OF COMPUTER NETWORKING IN AFRICA
Fido systems in Africa
Barriers to Effective Computer Networking in Africa
Reasons for choosing Fido
FIDO SOFTWARE
A User Perspective
Deficiencies of current user software
Developing the user software
Developing the host software
Billing software
Gateway software
DOCUMENTATION
Documentation for user software
Host documentation
Billing software
Gateway software
TRAINING
Needs for a successful training programme
Training proposal
CONCLUSION
Appendix A - Global Networking Workshop Participants
Appendix B - Computer Networking Initiatives in Africa
Appendix C - The Components of Fido Software
Appendix D - Developing User and Host Software
Appendix E - Billing Software Specification
Appendix F - Gateway Systems Specifications
Appendix G - Documentation Work Plan
Appendix H - Training in Electronic Communications in Africa
PREFACE
Computer assisted communications for NGOs in Africa was the focus of an intense technical workshop that brought twenty-five people from around the world to Toronto from February 1-14, 1992. The operators of seven African networks joined with operators of 4 Association for Progressive Communications (APC) hosts and as well as other technical experts from North and South to assess the current situation and lay plans for the future. This report is based on the findings of the workshop and represents the collective effort of those involved.
The goal was to establish the requirements necessary to bring the existing semi-experimental African computer communications infrastructure to the point where it can provide a reliable and efficient service for NGOs in the region. The assumption was that the African experience would also provide lessons and guidance for the rest of the developing world.
The general objectives outlined at the start of the workshop were:
1) To review the status of electronic mail systems in Africa, particularly those in the hands of NGOs and academic users.
2) To assess and redress the technical problems associated with the use of systems currently in operation.
3) To review alternative strategies for the future development of electronic mail (email) in Africa and suggest optimum solutions to cover the next 5 years, taking into account technical and telecommunications infrastructures.
4) To develop a plan for the sustainable transfer of email technology to those on the ground in Africa.
5) To produce a document for publication and for use in coordinating approaches to funders for future development.
In addition to working to meet these objectives two public forums were held - one in Toronto and one in Ottawa. Over 130 people from local Canadian NGOs and funding agencies attended these forums to learn how computer communications is developing throughout the world with an emphasis on Africa. The forums generated tremendous interest in the actual and potential benefits of this type of communications both for South-North and South-South information exchange.
The gathering unleashed a tremendous spirit of cooperation, information sharing and brainstorming. Using electronic mail many of the participants had built up long standing relationships with others over many months prior to the conference and this was the first opportunity for a face-to-face gathering. The workshop was a resounding success. (A list of the participants can be found in Appendix A.)
The Technical Report of the Global Networking Workshop is a summary of the face-to-face discussions that took place at the workshop and the on- line discussions before and after.
Special thanks to our funders, Partnership Africa Canada (PAC) and the International Development and Research Centre (IDRC) for their wholehearted support of the project. I would also like to extend special thanks to the Southern Africa Resource Centre, the Ontario Council for International Cooperation, Alternet BBS (Ottawa), OXFAM-Canada and especially to all the staff at Nirv Centre, who ensured that everything went smoothly from start to finish.
Arni Mikelsons, Workshop Organiser
INTRODUCTION
Since the mid-1980s electronic networks have increased in importance and usefulness as a tool for development and social change. A stimulus for this emergence has been the need to move information to, from and between developing countries, where information is a commodity often beyond the economic means of NGOs and even academic communities.
Three years ago, there was no NGO computer communications facility in Africa. To communicate with an electronic network, a long distance call to Europe or North America was necessary.
Since then, host systems have been established in Zimbabwe, Kenya, South Africa, Tanzania, Zambia, Ghana, Senegal and Ethiopia. This ground- breaking work has provided an excellent pilot phase during which technical viability has been proven and future needs have been identified.
On first consideration, computer communications in Africa would seem an inappropriate form of development when basics such as food, sanitation, clean water and health care are in short supply. In fact, computer networking is the ideal tool for enabling and improving communications in these areas because it makes such efficient use of scarce resources.
Computer networking is far cheaper and more convenient than facsimile or telex wherever even the most basic computer is available. Since cost of use is one of the most crucial factors in democratising the use of telecommunications systems, these new messaging techniques offer considerable potential towards achieving this goal.
Africa presents a challenging environment for computer communications.
Efforts have been made over the last year and a half to evaluate the available communications software and assemble a suite of standardized communications programs to meet the needs of the African NGO community. This has been tested on over 100 installations and the Toronto Workshop was the culmination of this phase of experimentation.
The operators of African computer communications systems identified the following are the most needed components to make fully functional networking systems more widely accessible. Four areas of software development were identified:
- - user software enhancements
- - host system improvements
- - message tracking and billing software
- - gateway software to other networks
- - host system improvements
It was also clearly identified that training and long-term support of users is an essential ingredient in the operation of sustainable computer networks.
Based on their collective experience over the past several years, the workshop participants re-affirmed their commitment to work collectively and to support agreed-upon standards for software and communications protocols.
OVERVIEW OF COMPUTER NETWORKING IN AFRICA
More and more NGOs have the necessary equipment for communications, having obtained computers for other tasks such as word processing and database operation. Communications software is usually free or very cheap. Modems are often a substantial expense (US$100) where hard currency is scarce and gaining access to telephone lines can present a major obstacle.
Fido-type systems are now operating in Senegal, Ghana, Ethiopia, Kenya, Tanzania, Zambia, Zimbabwe and South Africa. Interest from users and potential system operators is growing beyond these countries as well. Conforming to international inter-host communication standards, these systems are beginning to provide a cheap and reliable link between institutions within Africa and to the international community of NGOs and research organisations.
Many of these systems find roots in Interdoc, an international and interdisciplinary partnership of NGOs and NGO networks using information for social change. Interdoc has members on most NGO mailbox systems. At the last Interdoc conference, held in Epe, Netherlands in May 1990, Fido was chosen as the appropriate protocol to be used by systems, including many in the north, because it is a relatively inexpensive and easy-to- learn system. This standardization has enabled systems to communicate with each other using one protocol.
Shortly after the Epe meeting, a Fido gateway was installed at GreenNet in London. Initial experimentation with the gateway was carried out by ELCI and Mango which installed Fido mailers at about the same time. Concurrently, WorkNet commenced work on a Fido gateway for it's Major BBS System.
Since then, the GreenNet Fido gateway system (GnFido) has been upgraded to cope with the steadily increasing traffic. In the three month period from October 7, 1991 to January 5, 1992 over 70 different Fido systems mainly from Africa and Eastern Europe called into GnFido, transferring close to 6,000 messages. Fido gateways are also in operation at other APC nodes, including IGC in the USA, Web in Canada, Pegasus in Australia, NordNet in Sweden and ComLink in Germany.
Fido systems in Africa
As of February, 1992, there were eight Fido systems in Africa operating as hosts for about over 100 end users who are able to send and receive electronic mail and conferences. (For more information on computer networking projects in Africa see Appendix B.)
These systems are operated by a broad range of different organisations:
- quasi-state bodies like the Centre for Scientific and Industrial Research in Accra, Ghana;
- international non-governmental bodies such as the UN Economic Commission for Africa in Addis Ababa, Ethiopia;
- single large International NGOs like Environmental Liaison Centre International (ELCI) in Nairobi, Kenya;
- coalitions of NGOs as in MANGO in Harare, Zimbabwe;
- autonomous NGO service organisations such as WorkNet in Johannesburg, South Africa.
Systems currently operating 24 hours a day are in Addis Ababa (PADIS), Dakar (ENDA), Johannesburg (WorkNet), Harare (MANGO) and Nairobi (ELCI). Some systems run on 386s with 120 MB hard disks, some run on slow XTs with only 20MB hard disk. An XT is adequate to serve the needs of 15-50 users when Fido software is used to automate and compress message transfers.
Each host has a Telebit T2500 dual standard modem connected to a single phone line. This modem supports high speed links (9600 or 19200 baud) as well as the standard 1200 and 2400 baud. The standard speeds are mainly for users, while the high speed links provide gateways to systems of the Association for Progressive Communication (APC).
The APC is a community of 11,000 NGOs and individuals in over 90 countries on 10 hosts in Australia, Brazil, Canada, Germany, Nicaragua, Russia, Sweden, Uruguay, UK and US. Messages can be sent through these machines to outbound fax and telex servers, and to commercial hosts such as Dialcom and GeoNet. In addition, the APC provides access to researchers on the various university computer networks that form part of the Internet, JANET and BitNet worldwide, and Uninet in Southern Africa.
For many communication purposes, sending files and messages directly to another individual is all that is necessary. However, there is also the opportunity to 'broadcast' the message to a select group of participants. These 'mailing lists', also known as electronic conferences or bulletin boards, can be publicly available to anyone on any of these networks, or restricted to a select group - for example a coordinating committee. The sender does not have to know the electronic address of each participant to send each a message, instead a single message is sent to the predefined mailing list running on the host which then decides which systems to pass the message to. The list can comprise an unlimited selection of fax numbers, telex numbers, electronic mail addresses and bulletin boards or conferences running on certain hosts.
Conferences are usually based around a particular topic and can last for a short period or proceed for an unlimited time. They can be discussion- oriented or news and information oriented. For example, all workshop participants contributed to an electronic conference before arriving in Toronto. This allowed everyone to read background material before they arrived, despite the fact that some papers were "published" only days before people arrived in Toronto. Currently, there are about 3000 topic- related conferences that are available through the APC and academic networks.
Fido technology is proving itself in the field - not only in Africa. A growing number of NGOs worldwide are adopting the system for their communications requirements.
Barriers to Effective Computer Networking in Africa
Africa operates with poor telecommunications infrastructure which is not conducive to the development of data communications. Telephone densities are as low as 0.1 percent of people. In the vast rural areas, where 80 percent of the population lives, there is often no access to basic telecommunications facilities.
Specific barriers include:
- poor switching equipment which results in incompatible signalling systems between countries;
- unreliable primary power sources which cause numerous telephone traffic disruptions;
- lack of trained staff to maintain the networks and keep abreast of newly emerging technologies;
- inappropriate management information systems for monitoring operational status of the networks;
- insufficient funds for system management and maintenance;
- continuous deterioration of lines due to climatic conditions for which the equipment was not calibrated by the manufacturer.
In addition to the above technical difficulties, the development of computer networks is hampered by telecommunications policies.
They include policies regulating:
- - the import and use of telecommunications equipment;
- - tariff structures;
- - network traffic and structure;
- - the quality of service and management of telecommunications networks;
- - regional and international cooperation of telecommunications development.
- - tariff structures;
Reasons for choosing Fido
Over the past three years many options have been analysed, these can be divided in three distance areas:
- multi telephone line interactive UNIX based systems such as those used by APC and academic networks in northern countries;
- DOS based FIDO systems;
- other DOS base systems such as Major BBS and Waffle.
Multi-line, interactive, UNIX-based systems, which are used by NGO networks in developed countries are also not appropriate. Phone lines, even just one, are very difficult to obtain. For example, it took almost two years for the host MANGO in Zimbabwe to obtain a phone line. Bad line quality also makes interactive on-line communication virtually impossible.
A further barrier to using interactive systems is the requirement of a skilled Unix system administrator. It is often very difficult for NGO systems to attract staff with these highly valued skills. A capable Unix administrator is difficult to find in a developed country. People with these skills can demand high wages anywhere in the world, in many developing countries NGO based networks have been unable to keep people from seeking attractive opportunities in the private sector.
The current consensus is that DOS-based communications software based on FIDO is the most appropriate solution for many African host operators.
There are four main reasons for choosing Fido:
- the technology optimises the use of few, low quality phone lines;
- FIDO software is relatively inexpensive and often free for non-commercial use, running on all low cost computers from floppy disk PC to Macintosh Classic;
- it is becoming very easy to use as programmers continue to refine it;
- its message format is such that information can move between FIDO and multi-line NGO, academic and commercial networks which dominate northern networks.
Although there are other low-cost, easy to use DOS-based systems in the world, there is no other system that will work on low quality phone lines. Throughout much of Africa it is essential that the chosen software deal with poor quality phone lines. FIDO offers the following features:
- the z-modem file transfer protocol which is automatically has a high level of resiliency to line noise and satellite delays, and continuously adjusts the packet size to appropriate values;
- if the connection breaks while a file transfer is taking place, the transfer picks up where it left off on the next call. This feature is particularly important when transferring large binary files, where the chance of losing the connection over poor quality telephone lines is high;
- with a 2400 baud modem, users are reliably achieving transmission speeds of 220 characters per second (cps), even on relatively poor phone lines;
- with automatic file compression before transmission (to one third of the original size), it is possible to send or receive about 40 000 characters (about 6 500 words) during a one-minute call. This means that sending an electronic message costs between 1% and 10% of the equivalent fax transmission cost, depending on the speed of the modem and the size of the message;
- For the cost of about US$700 a high speed modem can be purchased when the volume of communication makes it more cost effective. Depending on the quality of the phone line, a modem such as the 9600 baud Telebit Trailblazer (TM) can transmit data 3 to 8 times faster than the 2400 baud mode.
Other reasons for choosing FIDO include:
- most NGOs in Africa are familiar with programmes that run under DOS, adding DOS-compatible FIDO software does not require an entirely new set of skills. Whereas, operating a Unix host would require and entirely new skill set;
- built-in cost-effectiveness: FIDO was developed in North America and Europe, by computer enthusiasts or "hackers" who needed a low-cost means of communicating and transferring their newest programmes;
- an existing user base of over 13,000 FIDO systems means that the technology is well supported;
- in Africa, where a system is fortunate to get one phone line, using data compression and automated file transfer means that it is possible for a host to support 50 or more users on a single mediocre quality phone line.
The reason this highly efficient and resilient technology has not immediately penetrated the developing world is that it was developed by computer enthusiasts for their own use, and not designed with the novice computer user in mind. The software has steadily been getting more sophisticated and intuitive to use. Because it is an open standard, hundreds of different programmes have been written to perform various Fido networking tasks: message readers, file compression utilities, log file analysers, conference mail processors, a message routers, etc. Assembling a working Fido communications system has until recently been a task reserved for the very computer literate.
FIDO SOFTWARE
A User Perspective
From the user's perspective, a Fido system is unlike the standard 'dial- up' host in the North. The user does not interact directly with the host computer by manually entering commands via a terminal programme. Instead, the user only interacts with the computer when it is not on the phone. This is also known as an "offline reader" approach. (For a description of the components of Fido software, see Appendix C.)
Using this software is more like sending a fax than going through the series of 'log on' and 'upload' procedures necessary connect to a remote host. Together with file compression, this method of communication typically reduces the length of the phone call by 80-95% compared to the time taken for a manually controlled session with the host.
E-mail and conference messages are prepared in an editor which can be preset to use Word Perfect or Word Star type commands. To send the messages to the host computer, the user simply presses one key. Then a 'bundle' of mail is created as the programme scans the message base for all new messages. These are then sent to the remote machine as a single compressed file. This takes place without further instruction from the user. Once the software is configured for local conditions, the interaction between computers is entirely under the calling computer's control. Whenever a call is made, any waiting messages at the remote end are also picked up, automatically unpacked, and placed in the user's mailbox.
Such a system can also be left switched "on" for longer periods, in a state ready to receive and send messages to and from other such systems. Having received a quantity of information from a remote host it is possible to set the computer to automatically pass it on to another user's machine who may need the information. In this way a user can become a 'host' simply by arranging to have the machine left running on a regular daily or weekly schedule.
Researchers in the field can also use this system by pre-arrangement to place calls directly to other users without having to access the host. This flexibility is particularly important for sending secure or urgent documents directly to the recipient's machine. Password controlled sessions and text encryption can also be simply implemented if necessary.
The equipment does not require the installation of a separate telephone line - existing voice or fax lines can be temporarily diverted to the modem while it places the call.
Deficiencies of current user software
A number of problems with the current bundle of programmes were identified.
The following is a list of some of them:
- configuration of a software installation relies on too many separate setup procedures. A user should be able to simply enter the number of their host; their point number; the conferences they want; and where they want the programme installed, i.e. drive and subdirectory;
- prompts are generally in English, although some progress has been made to convert to French. Conversions should also be made to Portuguese, Arabic and possibly Swahili;
- although the editor can emulate different word processor keystrokes, such as WordPerfect's or Word Star's, it should be easy to switch between them;
- the current package only works on a hard drive. An installation that works with only floppies should also be developed;
- a simpler addressing system must be developed, preferably one which refers to the system name rather than the userid;
- Fido systems need an easier way to send Internet messages. It is possible for Fido system to send Internet messages through APC gateways, but the onus is on the user to get a very difficult address right in a very awkward way. If Fido systems could understand this format, this task, especially important at universities would be made easier.
Developing the user software
A number of software development priorities were drawn up by participants of the Global Networking Workshop.
Work on the user software involves developing an installation package and removing several non-essential features. It is also essential that an arrangement be made to include a text editor which can be freely distributed with the user software. Negotiations are currently under way with the author of the GoldEd editor.
Specific software modification include:
- preparing a menu-driven installation programme for the user;
- incorporating a context sensitive help system into the current software;
- adding "point and click" subscription to conferences;
- incorporate changes of a requested user list to the current nodelist as an automated procedure;
- tool to show amount of time spent on line;
- designing a compiled version of the software;
- removing features normally only required by host software.
The above are specific modifications which need to made immediately. The following tasks need to be addressed before long-term development decisions can be made about future development paths.
- Evaluate ease of use of the current software configuration and improvements that could be made;
- Evaluate the possibility of using Internet style message format (RFC 822/1023/1036) instead of the Fido message format.
Developing the Host Software
The host software is run on a central computer which communicates either internationally or with another network in the region.
The most urgent need in this area is to provide appropriate documentation for system operators. This documentation should outline aspects of technical operations and provide a basic guide to systems adminstration. A number of critical lessons have been learned about system operation and administration and it is important that these be passed on to new system operators.
Specific required modifications to the existing host software include:
- improvements to the ability to monitor and account for messages moving to and from the system, this requirement is essential for the installation of an effective means of billing for these messages; (See Appendix E: Billing Software Specification);
- improved systems for addressing messages to and from academic, commercial and nonprofit systems in the developed world;
- developing utilities and programs to make the software multi-lingual;
- installing better systems for maintaining on-line conferences;
- an easy-to-use and robust billing system to invoice for both local system usage and international electronic mail traffic.
For a fuller discussion of the development of user and host software see Appendix D.
Billing Software
There is an urgent need for a comprehensive but simple invoicing package for host operators with systems less than 300 users. Numbers are likely to be around 30 to 100 users. No such software is currently available.
The ability to charge efficiently and accurately for services is crucial for NGO hosts. Many are not willing to open their services to third parties until they can start recovering costs from senders. Billing software is an essential setup in developing access to computer communications in Africa and elsewhere.
A billing programme would need to:
- - import data in the form of text or delimited files;
- - batch process it for invoicing all users on a regular basis;
- - create itemized lists, reports and invoices;
- - track payment/non-payment;
- - include flexible configuration for any currency, for prompts and help in different languages, for different charge rates;
- - ability to charge sales tax;
- - be free, or available at low cost.
- - batch process it for invoicing all users on a regular basis;
This programme would take the file generated by the message tracker and create billing output. Currently conference volumes are not being tracked. It is likely that there is software available to record the traffic in bytes. A survey of the software will need to be carried out and additional tools will be required to extract the totals for billing purposes.
The billing software is not intended to be an accounting package. It will only deal with invoicing and payments received for use of the host. Most organisations running hosts already have an established accounting system (manual or computerised). If not, the most appropriate source of advice and support to create one will be other similar local organisations.
(See the proposed billing specification in Appendix E.)
Gateway software
An essential ingredient in the establishment of sustainable electronic communication systems in Africa is the efficient movement of messages from the FIDO-based systems to systems used by the larger electronic mail networks in developed countries. These larger networks use a style of message formatting called Internet addressing or in technical terms, RFC 822/1023/1036 mail/news format.
For example, delays in the exchange of messages between points such as Harare and Ottawa are not the result of international communication problems. Delays are most frequently caused by interruptions in communication between a FIDO computer and a UNIX computer, both of which are located in Toronto. These interruptions are a result of poor software which frequently requires human intervention. A more efficient and robust piece of "gateway" software is required to eliminate this barrier.
The following features were those identified as necessary:
- - binary file transfer;
- - X-25 access;
- - auto conference management;
- - delivery confirmation, or guaranteed error confirmation;
- - no script necessary on Fido mailer;
- - simplify header in message transfer;
- - Fido user lists on APC, APC user & conf lists on Fido;
- - maintainability and reliability (minimize need for technical staff's attention to gateway);
- - instalability (develop model for easier installation of Fido gateways at other APC sites);
- - ability to split large messages;
- - training and documents of gateway for APC technical staff;
- - tunnel tracking i.e. tracking messages sent through APC systems from non-APC networks to Fido systems.
- - X-25 access;
A Gateways working group met and came up with three suggestions for improving gateways in a variety of different situations.
1. A Unix-based Fido mailer that converts between 'Fido' and 'Internet' (Uucp) and allows the UNIX host to accept calls from both Fido and other UNIX hosts.
2. A DOS-based UUCP package that converts between Fido and Internet allowing a DOS Fido host to make calls to (but not receive calls from) a UNIX host.
3. Longer term plans to create a convergent path whereby 'Internet' messages can be transmitted using 'Fido' transfer protocols.
(For further discussion on gateways, see Appendix F.)
DOCUMENTATION
Documentation was identified as a crucial need for supporting use of electronic communications in Africa. Each component of software should have accompanying comprehensive documentation. Each set has a different audience, so would have to be written at a different level.
In general, software that is to be used in Africa should include the following features:
- an orientation towards a more "hand-held" approach using visual depiction of actual screen images (screen dumps);
- a more comprehensive overview of what Fido is, how it works, and why it is appropriate in the African context with more visual images demonstrating, for example, file routing;
- a complete glossary with detailed descriptions of the individual components of the system;
- a complete index;
- flexibility for customizing to individual sites, for example University users are interested in Internet gateways and addressing;
- availability in French, Portuguese and Arabic;
- should be based on existing documentation.
(For a fuller discussion of documentation see Appendix G.)
Documentation for User Software
Some documentation exists for user software. Although it has served users in several African countries, it has been assembled on a volunteer basis and is incomplete. This documentation accompanies the manuals that come with the Fido software. These manuals generally are too technical for the average user, so the user software documentation should be written to stand alone.
The Workshop identified several areas where improvements could be made. The documentation should include:
- standard methods of addressing other networks such as Internet, BITNET, JANET, etc from Fido and vice-versa;
- how to participate in an electronic conference;
- how to subscribe or unsubscribe to a conference;
- instructions on how to make a point or node system configuration to diskette using menus. Note: a more detailed description of this is in the host documentation;
- translation of the documentation into French, Portuguese and Arabic. Note: there is a an early version of the documentation in French;
- a separate trouble shooting guide should be enlarged and restructured from the current one for easy reference;
- a complete index;
- flexibility for customising to individual sites, for example University users are interested in Internet gateways and addressing;
- a summary or single-sheet quick reference guides.
The development of the documentation should occur concurrently with the development of the user software.
Host Documentation
The host software documentation will be different from the user documentation in a number of ways. The documentation will reflect the comparative complexity of running a node.
Particular focus is on maintenance procedures for host node operation: expiry of conferences, trimming log files, analysing log files, accounting, scanning incoming message and file areas, nodelist updating, monitoring disk space, modifying routing and redirect commands, adding/deleting public/private conferences, checking on transfer rates.
The host documentation should go into greater depth on how to install point or node configuration on a new system. It should also cover typical problems that occur - modem, serial port driver, config.sys, menuing systems, telephone exchange system, telephone operator calls, mice, other COM port access problems. In a sense, this would be a more detailed troubleshooting guide. It should cover tuning of conferences and address/nodelists to suit the user, including cc lists.
The host documentation must also go into depth on how FidoNet works, how to connect to systems outside FidoNet, including APC systems, university sites in JANET and BITNET and how the different Fido programmes fit together, including ones specific to running a host.
The workshop identified a number of areas that should be covered in the host documentation. They were:
- - better description of how routing works;
- - how to maintain conferences;
- - troubleshooting ie. reasons a user is not receiving a conference;
- - participating in online technical and policy conferences;
- - a greater overview of different systems in existence and how to reach them with particular focus on addressing;
- - instructions on installing modem and telephone line;
- - a separate or much enlarged guide to modem trouble shooting needs to be assembled from the available manuals, and postings, etc.
- - how to maintain conferences;
Specific programmes needing documentation are :
- - "gofdhost.bat" the DOS batchfile that runs the host;
- - useful utilities (MessageTrack, split, redir, etc);
- - tosser/scanner software and maintenance programs;
- - error levels and corresponding functions in "gofdhost.bat";
- - adding interactive BBS software like Remote Access.
- - useful utilities (MessageTrack, split, redir, etc);
By splitting the documentation into generic and specific formats, changes that will be necessitated by upgrades in software will be localised to the specific format. This format also leaves the option for more demanding systems to use different software than hosts that are not starting up.
In addition to the host documentation that must be created, most of the programmes that are used do have documentation that is included any set up. This is often very technical in nature, but for a host operator, these documents are quite useful. Also included with every installation is a document called Policy 4, which is the Fido policy document.
Billing Software
The billing software was identified as a crucial element of the host set of software. The documentation for the billing software should be included with it. It should also follow the same recommendations as outlined for all software destined for Africa.
The documentation for the billing should be ready for release with the software.
Gateway Software
Documentation exists for the running of UFGATE and RFMAIL, the two main gateway programmes. In light of the development of the software, changes will need to be made to the documentation as well.
TRAINING
Training of system operators and users was reviewed at the workshop. Generally the model for training has been an "expert" going in and teaching local people how to use the technology. Usually this person also is responsible for running a node.
Training starts with a software demonstration, and includes identifying the communication needs of the organization. Training and training materials are given at time of installation. Generally the training period lasts about a week, and is then followed up by periodic visits/support, and ongoing online support.
Although expatriates started the training process, this is starting to be transferred to African system operators as well.
Perhaps the single most important institution to support a local network is a user group. User groups develop around a host and span the spectrum of users. Often, people from NGOs, universities and parastatals will participate. The user groups act as a bridge between institutions and can be used to guide and support development of networks in the absence of official institutional links.
Needs for a successful training programme
A number of areas of need were identified for a successful training programme. These included:
- demonstration equipment and software. This would include access to an adequate number of phone lines (at least two);
- more technical (computer hardware) training for sysops;
- educational materials for managers/directors of host organizations;
- good reference materials (especially in areas where communication is generally difficult);
- Fido tutorial as well as context-sensitive help;
- translations of software and materials in English, French, Portuguese, and Arabic;
- trainers who fluently speak the language of the people they are training;
- sysops need to be able to train users;
- technical support people need independence from host organizations (for logistical and political reasons)
Training proposal
Training needs to happen on three levels: for end users, for node operators and for trainers.
Users would primarily receive training through the node operator and support through the user groups or user councils. The fact that the node is operated by different types of organisations should not matter.
The node operators would receive training from a node training team, which would consist of two people - a trainer and a training assistant or associate (depending on initial qualifications). At most one of these people should be a non-African. This training team would be based in Regional Centres throughout Africa. The logical place for such a team would be at existing nodes, for example Nairobi (ELCI), Harare (MANGO), Dakar (ENDA), Cairo (ALDOC), Johannesburg (WorkNet) and Yaonde (proposed new location). The training team would provide support to existing or proposed nodes through scheduled visits every four to six months and through online help. They would also hold regular regional workshops.
The trainers, who would most likely be existing node operators or advanced users, would need the necessary equipment and training material and a budget for salaries and travel. Some of the training material could come from the documentation, and existing training materials, but other materials would have to be designed.
The regional trainers would be supported and coordinated by a central office that would administer funds for the project. It was proposed that PADIS, which is a UN affiliated organisation based in Ethiopia, could provide this role. It was also considered important that the regional teams be organisationally separate from the node host.
(For a more detailed look at training see Appendix H.)
CONCLUSION
Since the establishment of pilot Fido communication systems in Africa, three years ago, computer networking has rapidly become a reliable effective from of communication. The participants in the Global Networking Workshop were brought together to identify networking obstacles and to plan ways to overcome these with the hope of advancing African networking from the experimental stage.
Despite the fact that Fido software was not written with ease of use as a primary concern, it is very effective tool for communications over a limited number of poor quality phone lines. A lot of work has been done to make the software easier to use. This work has been done by people in Africa or by people who have lived in Africa. The focus of this work has been the creation of a menu-driven off-line reader, intended for use by people with limited computer knowledge.
More work still has to be done, including:
- - developing user software that is menu-driven, easy to
install, and available in different languages;
- - developing host software that monitors message traffic, generates invoices, and is multi-lingual;
- - developing gateway software that works in a variety of scenarios: gateways on UNIX systems that handle a high volume of African mail; gateways on the African host to UUCP systems, Internet-style message transmission using Fido protocols;
- - writing comprehensive documentation to accompany system software in the major languages in Africa;
- - developing training programmes that will ensure that computer communications skills are transferred to trainers, system operators and users.
- - developing host software that monitors message traffic, generates invoices, and is multi-lingual;
Much of this work will be done in Africa and will involve the workshop participants and other system operators from Africa. Coordination will take place primarily through computer networking and possible future face-to-face meetings.
Arni Mikelsons and others, 1992. Technical Report of the Global Networking Workshop, held in Toronto (Canada) 1 to 14 February 1992. Posted on VITA Distribution Service 15 Nov 1992. Filename, available in 3 separate parts as africa_workshop1.txt, africa_workshop2.txt, africa_workshop3.txt.) Total filesize, 135 kB.
Appendix A
GLOBAL NETWORKING WORKSHOP PARTICIPANTS
- David Balson, International Development Research Centre, Canada
- Karen Banks, Institute for African Alternatives, England
- Mark Bennett, Satellife, ESANET, University of Zambia, Zambia
- Randy Bush, operates Fido zonegate to Africa, USA
- Moussa Fall, Environment Development Activities, Senegal
- Bruce Girard, Resystom, Canada
- Viv Kendon, GreenNet, England
- Mike Jensen, WorkNet, South Africa
- Adam Lishan, PADISNET, Ethiopia
- Mohamadu Alhaji Mahamadu, Council for Scientific and Industrial Research, Ghana
- Arni Mikelsons, Workshop Organiser, Canada
- Wayne Morris, Resystom, Canada
- Jagdish Parikh, NGONET, Uraguay
- Miguel Peirano, NGONET, Uraguay
- Gillian Phillips, NGONET, Canada
- Micheal Polman, Antenna, The Netherlands
- Doug Rigby, Environment Liaison Centre International, Kenya
- Kirk Roberts, Nirv Centre, Canada
- William Sangiwa, Commission on Science and Technology, Tanzania
- Geoff Sears, Institute for Global Communications, USA
- Bob Thomson, Consultant, Canada
- Karen Banks, Institute for African Alternatives, England
Appendix B
COMPUTER NETWORKING INITIATIVES IN AFRICA
Prepared for Global Networking Workshop, Toronto Feb. 3-7, 1992 Prepared by Mike Jensen, Consultant and acting Systems Operator WorkNet (South Africa).
The following is an overview of some of the computer networking projects under way in Africa before the Global Networking Workshop.
The different initiatives have different players, but support each other. Most of the descriptions are of projects that are supporting several nodes. Worknet and Mango have a slightly different beginning in that they were first set up as bulletin board systems servicing South Africa and Zimbabwe respectively, before they started networking to other systems.
1) NGONET Africa.
The NGONET Africa project is based at the Environment Liaison Centre International (ELCI) in Nairobi where a Fido bulletin board system has been set up to provide a conduit for electronic mail traffic in the region and to NGOs worldwide. This is done using a high-speed modem to make daily calls to the GreenNet Fido gateway in London. The project is also supporting the MANGO (Microcomputer Assistance for NGO's) Fido bulletin board project in Zimbabwe (see below) and is assisting in the establishment of a third bulletin board system in Dakar and another in Tunis, Tunisia.
An earlier survey found there were significant numbers of NGOs that had computers but were not using electronic mail yet. A total of 48 NGOs are being identified to receive modems, training, documentation and support. Also, support is being given to improving the flow of electronic information around the preparations for the UNCED conference in Rio, Brazil in 1992 by subsidising some of the long distance phone costs to bring the information into Africa.
To provide NGOs with the cheapest access, emphasis is being placed on establishing a series of hosts with high speed modems distributed throughout Africa. These can then provide NGOs with local support and a local call to connect to the global electronic network. To this end four prototype hosts are being set up, one for each region of Africa - ELCI in Nairobi (East Africa), Mango in Harare (Southern Africa), ENDA in Dakar (West Africa) and ENDA-Arabe in Tunis (North Africa). ELCI, Mango and ENDA-Dakar are already established and ENDA-Arabe is expected to come on line before the end of the year.
Each of these systems is equipped with IBM compatible AT or 386 computers with high speed modems (Telebit T2500) providing PEP and V.32 9600 baud protocols.
2) ESANET
ESANET (Eastern and Southern African Network) is a pilot project to link researchers at universities in Uganda, Tanzania, Zambia, Zimbabwe and Kenya with each other and with researchers worldwide by installing electronic mail facilities at the computer centres of universities in these countries. ESANET is based at the University of Nairobi Institute of Computer Science. To maximise scarce resources, co-ordination and technical support is being shared with the NGONET project. Where there is no local NGO host system it has been agreed that NGOs will be able to use the resources of the campus-based nodes.
Nodes are currently being installed in:
Kampala - Makarere University - nodename MUKLA,
Nairobi - University of Nairobi - nodename UNICS,
Dar es Salaam - University of Dar es Salaam/Eastern and Southern African Universities Research Project - nodename ESAURP,
Lusaka - University of Zambia Computer Centre - nodename UZCC
Harare - University of Harare Computer Centre - nodename UHCC.
Each node runs a suite of Fido software on an IBM compatible AT with 40MB hard drive, high speed modem (PEP) and dedicated phone line. Zambia, Kenya and Harare can connect directly to the GreenNet Fido gateway (GNFido), while Uganda and Tanzania can only connect via Nairobi because direct dialling facilities outside the PTA (Preferential Trade Agreement) area are not available. Zambia has begun to experiment with direct dialling to London and the other nodes are expected to begin testing connectivity shortly.
3) HealthNet
HealthNet is operated by a Boston based NGO called Satellife which was initiated as a project of the International Physicians for the Prevention of Nuclear War (IPPNW). Satellife have purchased 60% of the capacity on the University of Surrey (UK) built Uosat-F satellite. This will initially be used to exchange health and medical information within the same Universities (coincidentally) participating in the ESANET project and via Memorial University in Newfoundland, Canada. Memorial is an appropriate site because of Dr. Maxwell House's work with telemedicine and because it is so far north the satellite passes overhead 10 times a day on its polar orbit.
Because of the total overlap in institutions in Africa, the HealthNet project is being administered by the African participants as part of the ESANET project to evaluate alternative data transport methods.
Although the current traffic is limited to health related issues, it will be up to the individual participating institutions in Africa to obtain clearance from the authorities for a wider interpretation of the health mandate. As far as the funders of the HealthNet project are concerned, this could encompass a much broader range of environmental and social issues. Currently however, only Zambia has been successful in obtaining approval for the installation of the ground station and this was with a specific medically oriented application.
The Zambian approval nevertheless sets a precedent for the authorities in the other countries. Also Zambia will now be able to host satellite traffic from the other participating countries via direct dial telephone lines with the ESANET Fido network until other ground stations have been approved.
More recently the Dean of Medical Studies at the University of Makarere in Kampala, Uganda has expressed optimism over approval of their satellite application which has an even broader mandate to include environmental information.
4) PADISNET
The Pan African Documentation Centre Network - PADISNET is a project to link 34 countries into a network of participating development planning centres which exchange databases and information. PADIS is based at the United Nations Economic Commission for Africa (UNECA) in Addis Ababa which also operates a Fido node connecting on demand to Accra, London, Nairobi, Johannesburg and Washington.
In Accra, the Centre for Scientific and Industrial Research (CIIR) is participating in the PADISNET project and have established GhastiNet, a 386 PC connected to an International Direct Dial (IDD) telephone line (needs to be specially ordered). This machine currently also operates as a host for the African Association of Universities and the Technology Transfer Centre. With only a 2400 baud modem calls to London are on demand, and polling PADISNET in Addis has not been successful. A high speed Telebit modem is arrived in Accra in the middle of December, which has helped polls to London, although testing is continuing.
NGONET and PADISNET project workers have held joint workshops. It is likely that the two projects will be able to share resources in the support of other nodes in Dakar-Senegal (CRAT) and Dar es Salaam- Tanzania (ESAURP).
5) WEDNET
Supporting research on women and natural resource management is the aim of the WEDNET project which seeks to link researchers in Senegal, Ghana, Burkino Faso, Nigeria, Sudan, Kenya, Zimbabwe, Zambia and Canada via electronic communications and conventional networking. WEDNET is also based at ELCI in Nairobi.
6) WorkNet
In South Africa, WorkNet operates as the national electronic network host for NGOs. The network has been established for about three years and now has about 180 users on a multi-user BBS programme called MajorBBS. Users include the labour movement, human rights groups, the alternate press, documentation centres, service organisations and church groups. The ICFTU (International Congress of Free Trade Unions) has funded the development of gateway software which allows MajorBBS users to send messages to other systems and obtain/post to online conferences. The MajorBBS format is converted to the Fido standard and a separate machine operates as a Fido node to transmit and receive the messages. The Fido machine is now officially registered on the Internet (worknet.alt.za) and is in daily contact with MANGO in Harare and the GreenNet Fido gateway in London via high speed (PEP) modem.
[Editors note: In March 1992, a proposal submitted to the Canadian International Development Agency by Nirv Centre, CIDMAA, and MATCH International to support and upgrade of WorkNet was accepted.]
7) MANGO
MANGO is a bulletin board service in Harare, Zimbabwe, operated by a collective of NGOs including: Africa Information Afrique (a regional news agency), IMBISA (Bishops Conference based in Harare), SARDC (Southern African Research and Documentation Centre), EDICESA (Ecumenical Documentation and Information Centre for Eastern and Southern Africa). It was recently agreed that the system be made available to the NGO community as a whole and a fee structure has been developed. MANGO now connects three times daily with the Web Fido gateway in Toronto. In addition it connects three times a day to WorkNet in Johannesburg.
8) ARSONET
ARSONET is a CIDA professional development project to link the African Regional Standards Authorities in Addis Ababa-Ethiopia, Dakar-Senegal, Nairobi-Kenya and Cairo-Egypt with Fido networking technology. ARSO has established a node in Nairobi which also connects daily to London. In Addis, users are connecting with PADIS for their host, in Senegal through ENDA and a separate system connecting directly to London will be established in Cairo.
The funders
This report comes out of work conducted in Accra, Dakar, Harare, and Nairobi, for the International Development Research Centre's NGONET & ESANET projects, and in Johannesburg for Soft Solution's WorkNet/GeoNet gateway project. Additional support was provided by the Institute for African Alternatives and the NGONET'92 project.
The International Development Research Centre (IDRC) in Ottawa, Canada is involved in helping to establish many electronic networks in Africa by funding the ESANET, PADISNET, WEDNET and NGONET projects described above.
The Institute for African Alternatives (IFAA), a decentralised, continent-wide policy research, education and publishing unit is working at electronically connecting its network of researchers and policy makers throughout Africa.
NGONET'92 is a project jointly sponsored by the IDRC and Dutch Foreign Office via HIVOS to improve southern NGO representation in the UNCED process and beyond. Based in Montevideo, Uruguay, the new APC node Chasque is in the same office.
Partnership Africa Canada (PAC) is a coalition of 84 Canadian non- governmental agencies supporting development work in Africa and/or involved in education work on Africa. PAC recently funded the Global Networking Workshop.
The Canadian International Development Agency is funding ARSONET and an upgrade to the existing WorkNet system.
Appendix C
THE COMPONENTS OF FIDO SOFTWARE
Prepared by: Mike Jensen Prepared for: Global Networking Workshop, Feb. 1992, Toronto
Introduction
Both user and host Fido software run on the same basic components. Each system has, at the least: a message editor, a mail processor, a FOSSIL driver (which runs the serial port), a routing file and a message tracker.
The only major difference between the host and the user software is that the mail processor in the host system typically has more features for handling greater volumes of traffic. The host will also make more use of tracking and routing software. A billing programme (as discussed below) is a necessary addition to the host set of software.
In order for a Fido system in the developing world to communicate with typical UUCP type systems in the north, a conversion programme is necessary to switch the formats seamlessly between the users of one type of system and the other. Usually called gateway software, this has been under development at GreenNet in London, Web in Toronto, PeaceNet in San Francisco, ComLink in Germany, Pegasus in Australia, Nordnet in Sweden and Paul Nash in South Africa.
Host Software components
The two most important components in any Fido system are the mailer and the mail processor.
The mailer is the programme responsible for sending, receiving and forwarding mail and files to other locations. On a host, the mailer runs inside a DOS batch file loop. After a successful file transfer with another location, whether that is a host system or a user, the mailer exits and the mail processor is called.
The mail processor takes all the mail received from another location and ensures that mail and conferences are routed to their destination. When it is finished processing mail the mailer is restarted, and waits for an incoming call or an instruction to make an outgoing call.
In addition to these two programmes, a number of others make up the full 'suite'. A message editor allows for reading and writing of messages, a message tracker logs how much and to where mail is sent, a compression programme reduces file size, and a FOSSIL driver runs the serial port. See Appendix F for a look at the major programmes in each of these categories.
The editor is not as important for the host since the host operator's primary concern is how mail and conference material moves through the system. The editor will be discussed in more detail under User Software. The message tracker will be discussed further under Billing Software.
Some hosts are also experimenting with Remote Access - multilingual software which provides an interactive access to the node for those without Fido software. This is not encouraged as a general practice because it ties up exclusive telephone line time, but for occasional use it is valuable. Since Remote Access provides a totally configurable interface, it would be useful to develop a standard configuration that hosts could adopt if they wish.
User Software
The user's software is different from the host software in some significant ways. In contrast to the resting mode of the host software where the Mailer waits on the modem for calls, the user's Fido programmes are accessed via a menuing system which presents the user with a variety of options - read/write a message, send/receive messages, update address book, subscribe to conference etc.
The batch files that tie these functions together have evolved steadily over the last two years through the work of Mike Jensen, Karen Banks and Arni Mikelsons. Known as FDM - Front Door Menu, they have provided a basic platform upon which to develop a relatively reliable and bug free operating environment for the user. The name came from the fact that the programmes relied on Front Door (TM) as the editor and mailer.
One of the important features of FDM is that it is possible for a user to 'clone' the existing installation for use by another user. The operator is taken through the various configuration files that need to be changed and the new configuration is compressed onto floppies (about 1.2MB is needed, using any variety of disk sizes). This can then be installed on another PC simply by issuing the INSTALL command.
To summarise the major differences between host and user software are:
- a user will, by and large only call one host, whereas the host will interact with different hosts through the use of the routing file;
- the host will also carry many more conferences and will carry all the waiting mail for its users and possibly mail to other systems if it is acting as an international hub. Because of these increased demands, a different conference manager programme might be used;
- the host will track volume of traffic, quality of connections, who is calling the system, be able to charge for international calls, and reroute traffic. There are programmes that will do all these functions, which are not necessary for the user software;
Presently, most users throughout Africa are running as a package, a selection of Fido software that consists of Front Door as the mailer and editor with GoldEd as an alternative editor. Imail, Tosscan, Scantoss and Gecho are used as mail processors, BNU is the Fossil driver and PkZip, ZOO, Pkarc, LHA and ARJ are used as compression tools. In addition, about 4 users are using Macintosh based Fido software - either Copernicus V 1.0 or MacWoof.
Appendix D
DEVELOPING USER AND HOST SOFTWARE
Prepared by: Arni Mikelsons, March 1992
CONTENTS:
Overview History and current status of software development System design The user software development plan Developing the host software
Overview
The user and host software will be developed in parallel. The user software will be a menu-driven programme, that is geared towards people that have limited computer literacy. The programme will be developed with the name "Easy Link to Fido" or ELF.
The host software will be done in two parts. First, a "host upgrade" to ELF and then an "advanced upgrade". The first upgrade will be for users who are interested in starting a host, while the latter is for established hosts.
History and current status of software development
The ELF user software will be based on a set of batch files, know as the Front Door Menuing (FDM) system. FDM is based on the Front Door (TM) suite of programmes, which until recently were the most developed available. Unfortunately, despite a number of efforts, an agreement with the author of Front Door could not be reached regarding the free use of the software in the developing world. Also, other programmes have recently been developed which are free, which are as good as or better than Front Door (TM) for the purpose of networking in Africa.
FDM has primarily been developed by the volunteer efforts of Mike Jensen, Karen Banks and Arni Mikelsons and has been installed for over 50 users in over 10 countries in Africa and elsewhere.
The Global Networking Workshop outlined many of the shortcomings of the user and host software. The following plan for ELF has been developed out of the recommendations of the workshop.
System design
The new software will be based on the existing user and host software, but will have to be redesigned to incorportate identified shortcomings. These include:
- design of user interface for both user and host software including making sure that system prompts and error messages can be translated into French, Arabic, Portuguese etc. (12 days);
- design for new functions of user and host features (9 days);
- design compiled version of user software (5 days).
The design of host and user software will be done be done in the short term (0 - 3 months). The work done in the medium term (3 - 6 months) will be done with the new designs in mind.
The user software development plan
Short term
In the short term (0 - 3 months), using the criteria set out in the workshop, final decisions will be made on specific pieces of software to be used. It is anticipated that the following software will be used:
- - GoldEd as editor with MsgEd for floppy installations,
- - Squish or Qmail as the mail processor,
- - Binkley as the mailer,
- - BNU as the FOSSIL driver,
- - ZOO as the compression programme.
- - Squish or Qmail as the mail processor,
If we are going to depend on these programmes contracts for the use of this software that is free for use in developing countries is crucial. All of these programmes are free or are at very low cost.
Tasks to be completed in this phase are as follows:
- develop final specifications for software suite including making final decisions on what software to include in ELF (10 days);
- decide on DOS compiler (2 days);
- Put all the new programmes into FDM.bat (5 days);
- logging software should be designed so that all the functions that it performs is done on one pass though the message base to minimise on down time of the system (5 days).
Medium term
In the medium term (3 - 6 months), the chosen software will be bundled together and distributed with limited documentation for testing. Comments will be made available online through a semi-private conference. Towards the end of this six month period, an official release will be made of this software under the proposed name of "Easy Link for Fido" or ELF.
Improvements that will be incorportated into ELF include:
- automatic incorporation of a requested user list to ensure that users have up to date lists of systems that can be mailed to. This is particularly important as new systems will be emerging in Africa on a regular basis (2 days);
- "point and click" (un)subscription to conferences. Currently a user has to manually change settings in three locations in order to (un)subscribe to conferences (5 days);
- have context sensitive help. Currently there is no help screens while in the menuing system. Most of the component programmes do have help screens and it is important to design a help system that will be in conjunction with these (5 days);
- have an easy to use setup procedure, taking advantage of the ASCII configuration files. Some Fido component programmes have binary configuration files, which are not easily accessible. In order to have easy setup procedures, it must be possible for setup programme to change the configuration files. This is possible with ascii configuration files (20 days);
- tool to examine amount of time spent on line, so that phone bills in countries without itemised telephone bills can be reconciled (1 day).
Some of the changes that are required for ELF, must be made in the component software, preferably by the author, which include:
- getting the editor to recognising @ symbol and mail to host. Currently, each user has the full lists of various APC systems on their hard drives, which takes up a substantial amount of space. If there was recognition of the @ symbol, a user in africa could enter a message to "idrc@web", and would know to sent the message to web, without having web's user list on their computer (7 days);
- editor to switch between WS and WP style commands. GoldEd has a configurable editor, but there is not easy way of switching configurations. Also, this could be expanded to other word processing packages, including ones in different languages (3 days);
- Set up a one floppy user installation. Despite the fact that the developed world is making 286 computers with 40 MB hard drives obsolete, much of the developing world still uses computers with only floppy disk drives. (14 days)
- Release test version of ELF for feedback in conjunction with documentation of the software. (2 days to prepare mailing)
Long term
In the long term (6 - 18 months), the user interface will be improved, most of the goals will have been incorporated into the software, full documentation will be ready, and it will have been fully tested before release. During this time a long term strategy for software support and improvement will be developed.
Activities in this phase include:
- Conduct software evaluation and incorporate results into ELF. This will be done in conjunction with documentation of the software. (20 days);
- Develop a sustainable, long term strategy for software support. One of the crucial elements to this software being used in Africa is the support it can get. A system of on-line support together with training must be devised for this purpose (5 days);
- Evaluate the possibility of using Internet style message format (RFC 822/1023/1036) instead of the Fido message format. This evaluation is crucial, as it will make connectivity of ELF greater, while keeping the interface the same. At the moment there is a number of ways this could be done, but there no path emerges as the one that will succeed in the end. An evaluation of this possibility in 6-12 months time would provide the necessary information to make ELF Internet compatible (10 days);
- Official release of ELF with documentation.
One of the key components that will be looked at in the long term is the possibility of using Internet style message formats (RFC 822/1023/1036) with the fido software. If this is possible, many of the problems with the translation of messages in one format to another would be alleviated. To date, no attempts have been made to do this.
Developing the host software
The host software is far less developed. It consists of a commented batch file and the technical documentation that accompanies the component pieces of software.
Two trains of thought came out of the Global Networking Workshop with respect to development of host software. On the one hand, it was felt that it should be possible to run a host with only a slight modification to the user software. This would make it possible for a user to start a host with a short training course, or diligent reading of the accompanying documentation. On the other hand, busy hosts need to take advantage of programmes that are more robust and will work faster to minimise the amount of time the system is off-line.
Both of these situations could be accommodated by two host upgrades. A standard upgrade would use the same component software as ELF, but have added modules that are required for running a host. The advanced upgrade would have further enhancements including software that may cost as much as US$500. Both upgrades would have both generic and specific documentation. See the documentation discussion for more details.
Conference manager capabilities are perhaps the most important addition to the host software. This enables the operator to establish and cut off conference feeds to users or other systems, a new packer, and a tool that allows one to edit compiled nodelist files and billing software.
One important and necessary feature of the host upgrade is the ability to track the performance of the system. This is done though tools such as message trackers, utilities for message format conversion and destination redirection. Most of this is done by separate utilities that pass over the message base several times. Incorporation of these tools together into one would save time and wear and tear on the hard disk.
Perhaps the most important of these utilities is the message tracking software which generates a listing stating the size of each message, who it was sent by, and who it was sent to. This file would be input into the billing software to generate invoices. Currently, one of the shortfalls of message tracking programmes is that they cannot track conference volumes.
Generally, the most important part of the host software is the documentation, as discussed elsewhere.
Short term
In the short term (0 - 3 months) final desisions will be made on programmes to be included in the standard and advanced host upgrades. Then, the new programmes will be incorportated into the batch file that runs the host -- GOFDHOST (2 days).
Medium term
In the medium term (3 - 6 months), new features will start being incorporated into the host upgrade to ELF. The following improvements will be included:
- Configuration for easy modification to routing files. Currently, the routing configuration file must be edited with a text editor (5 days);
- A conference management tool that is more geared to maintaining conferences. A user seldom has to perform many more functions that reading conference items, and deleting them if there are too many. A host operator will need to use tools automatically do these functions. The interface for doing this could be improved (7 days);
- Integrate and develop where necessary, tools such as message trackers, utilities for message format conversion and destination redirection, editors for compiled nodelist files. None of these tools are needed for the user software (12 days);
- Incorporate billing software into host system. See elsewhere for details on billing software itself (5 days).
Improvements must be made to the logging software. Some of these things are done by separately, but what is needed is a logging programme that will perform all of these functions in one pass through the message base. The features include:
- Log amount of traffic that is going through the system, who is sending it? where are they sending it to? This will form the basis of the billing software (5 days);
- Track conference volumes. Useful for billing users who will want networked private conferences and assessing costs of carrying various conferences (5 days);
- Recognise the @ symbol in a user@host string and to address the message to the "host". Currently, systems carry the user names of all people on various all APC systems, which takes up a lot of space on the users hard disk. If the system would recognise the host name, then the correct address could be inserted without having to know all the users on every system. (1 day)
- Scan messages for redirection to other systems, which could be users or hosts. Because of the addressing system in Fido, each user is a point. If a message is received on a host for Jane Doe, in the above format, the logging software will ensure the message gets translated into Fido language and goes to the correct point (3 days);
- Reformat the headers correctly, for systems that are internet gateways. This is to ensure that until the message reaches a gateway system the message remains in the fido format (8 days);
- Release test version of host upgrade to ELF. Evaluate ease of use of the current setup and improvements that could be made in conjunction with documentation of the system.
Long term
In the long term (6 - 18 months), the following activities will be performed:
- Conduct software evaluation and incorporate the results into ELF Host Upgrade. This will be done in conjunction with documentation of the software. (12 days);
- Official release of ELF host upgrade with documentation.
Appendix E
BILLING SOFTWARE FOR FIDO AND OTHER SMALL HOSTS
Prepared by: Viv Kendon, March 1992
CONTENTS:
- 0. Overview
- 1. Assumptions
- 2. Functionality
- 3. General system features
- 4. Specification of Data File Importation
- 1. Assumptions
0. Overview
The Global Networking Workshop agreed that there is an urgent need for a comprehensive but simple invoicing package for African host operators including ESAnet, NGOnet, Satellife and others. This package would also be useful for node operators in Asia and Latin America.
The ability to charge efficiently and accurately for services is crucial for African hosts, many of whom are not willing to open their services to third parties until they can do this. Billing software is thus an essential element in developing better access to electronic hosts in Africa and elsewhere.
Based on the experience of APC nodes, this kind of accounting is very specialised, and there is no option but to write a specific package for this. The thousands of existing FIDO hosts usually use a much simpler method of charging than we require, if they charge anything at all, so there is nothing in the general FIDO world that could be adapted for this purpose.
A few existing hosts have already developed their own billing systems, but they are unlikely to be universally applicable, well documented or supported, or up to the specification that we require. Existing programmes will undoubtedly provide useful ideas and experience in writing a comprehensive package. A survey and analysis of what already exists will be part of the work.
The billing system will import data generated by the host system and create invoices on a regular basis (eg. monthly), track payments, issue statements as required, and produce reports and summaries to enable the package to be integrated with other accounting systems.
The Billing Software is not a full 'accounting package' but an invoicing and accounts receivable programme.
The billing software will be designed for any host with up to 300 users not just Fido hosts, provided the host can generate usage data. Hosts with more than 300 users, may want to consider upgrading to a more sophisticated system.
The billing software will be part of the host upgrade of Easy Link to FIDO, and as such, free to third world users. It will be written in a commonly used language or application (such as dBase).
1. Assumptions
1. In the current standard Fido addressing scheme, where each user is considered a "point", point addresses should be used as account references;
2. each point on a node is a sales account and will be billed separately;
3. that messages originating from other nodes should be billed to the _node_ of origin (rather than a point).
2. Functionality.
a) Import of Data Files
Import any form of ascii, delimited file containing billing data. Several standard formats would be included (MsgTrack, APC fax and gateway data), and a facility to allow the operator to describe a new text file. See below for detailed specification.
b) Error trapping
When a message is detected that was originated by an unknown point or node, it will generate a warning and open an 'account'.
When it receives record of a charge about which it has no charge information, it will generate an error and allow the operator to create or modify charge information on the spot.
c) Look up & maintain account information
Besides the obvious address fields for each user/account/point/node, each will also record:
i) A 'user group' which will determine the rate at which they are billed;
ii) The 'currency' in which they will be billed (which may be pure bytes of traffic);
iii) A byte credit -- e.g. the first 10k (or 0) bytes not to be billed. (This could, alternatively, be an attribute of the user group);
iv) An optional subscription, which may be 0.00.
v) Accounts will be accessible by name and by point address.
vi) Fields that allow any combination of charge categories to be discounted to less than 100% of their usual value, or 'marked up' by specifying a percentage greater than 100%
The operator will be able to view or edit the above information. When viewing, the operator will also be able to view:
- The current balance of the account
- The transaction history for at least the current financial year.
d) Enter payments or credits received
This sub-system should allow entry of payments and entry of manual credits to correct errors in billing, issue a credit for something like receipt of an in-kind service.
- Payments information should include:
- account reference (username or point number)
- payee name
- payment date
- date received
- payment amount
- currency
- payment type (check; cash; credit card; correction; other credit)
- reference number (bank & check #; credit approval; other info)
- account reference (username or point number)
e) Enter zone information
Usage 'charges' be made according to the ultimate destination of the message in at least 10 rate codes:
- * Local -- on the same node;
- * A,B,C,...: -- specific zones, regions, or nodes can be assigned a rate code and may use 'wildcards'(more details on this upon request);
- * All other destinations/services where the rate = cost. This is used for fax and APC gateway charges that are supplied ready calculated, for example.
- * A,B,C,...: -- specific zones, regions, or nodes can be assigned a rate code and may use 'wildcards'(more details on this upon request);
If possible, there should be flexibility to add additional destinations and types of message traffic beyond 10.
Consideration of taxation requirements (which may vary from item to item) may also be necessary for inclusion into charge records. For example, a user manual may be exempt from sales tax, users outside the node's own country may be exempt, there may be more than one type/rate of sales tax to be applied, as in Canada.
f) Reports
All reports will be output to disk in a format which can be imported directly into Lotus 1-2-3 (TM) and other spreadsheets and programs, and will optionally be printed immediately. The minimum reports required for accounting purposes are:
i) Account history and balance for one account or for a wildcard-defined group of accounts;
ii) Monthly use ('billing') summary;
iii) Monthly cash-flow summary if appropriate;
iv) Aged debtors: how much owed that's 1,2..12 months old, or older.
v) charges to users sub-totaled by charge band to compare with bills for various services (the phone bill; APC gateway charges).
g) Invoices
The system will produce operator-configurable invoices. Fields available on the invoice form will be:
- - header information of node operator: Node name, address,
instructions for remitting payments;
- - paper size and orientation number of invoices to print per page;
- - user name & Address
- - system identifier
- - invoice date
- - period of charges
- - total amount due
- - current charges
- - past-due charges
- - date and amount of most recent payment
- - all details (may be omitted)
- - sub-totals for each charge band (may be omitted by operator)
- - paper size and orientation number of invoices to print per page;
- o Summary
- o History and Current Situation of APC - FIDO gateways
- o Justification/Motivation
- o Work Needed on RFMAIL
- o Work Needed on UFGATE
- o Budget and Timeline
- o Appendix: History and current situation
- o History and Current Situation of APC - FIDO gateways
- - a heavy load on the UNIX system;
- - a very poor data exchange rates over high speed modems;
- - do direct screen writes which interrupt processes on the console;
- - VPix is unable to share system resources;
- - a dedicated modem and serial port are required.
- - a very poor data exchange rates over high speed modems;
- - upgrading mailer software, likely to is SMAIL 3.1;
- - modifying login procedures to allow for RFMAIL functionality using John Haugh's shadow password suite;
- - Internet mail capability (exists at Web, required at GreenNet).
- - modifying login procedures to allow for RFMAIL functionality using John Haugh's shadow password suite;
- - fixed e-mail costs to and from most developed countries
including APC and academic networks;
- - integration with commonly used addressing standards;
- - reliability in terms of both time of message tranfser and assurance of receipt;
- - integration with commonly used addressing standards;
- - the full range of legal RFC822/1023 addresses (e.g. comments in
address fields)
- - APC node name abbreviations for proper FQDN addresses,
- - special characters in people's names, and
- - full compatibility with the DOS-based gateway programs.
- - APC node name abbreviations for proper FQDN addresses,
- - use the shadow password suite
- - smart mailer (SMAIL 3.1).
- * enable host system operators to confidently offer local on
and off line assistance;
- * enable users to refer to documentation which will answer the most frequently asked questions;
- * be informative and instructional enough to interest new users with little or no knowledge of electronic mail.
- * enable users to refer to documentation which will answer the most frequently asked questions;
- * outline.txt - an overview of electronic mail networking,
descriptions of GreenNet, GnFido and the Association For
Progressive Communications.
- * fdm.doc - a simplified version of the official Front Door Manual
- * frodo.doc - the official Front Door Manual
- * fdm.doc - a simplified version of the official Front Door Manual
- * poll.txt - FIDO/APC connectivity map
- * trouble.txt - the most commonly experienced modem, phone and conference maintenance problems
- * oxfam.q&a - some additional 40 or so 'commonly' asked questions from Oxfam, UK.
- * nodelist.txt - instructions for reading nodelists
- * fdguide.txt - see below
- * trouble.txt - the most commonly experienced modem, phone and conference maintenance problems
- - Introduction: Overview of Electronic Communications
- - what is a computer network, e-mail, gateways
- - Fido addressing
- - system overview
- - how different components work together (through batchfiles)
- - explanations of each part (editor, mailer, tosser/scanner, etc)
- - using the menu system
- - description of editors (GoldEd and Front Door)
- - reading messages
- - conference areas
- - addressing
- - making a new message
- - changing a message
- - description of the Mailer (Front Door)
- - quick reference charts for the editor (GoldEd and FrontDoor)
- - what is a computer network, e-mail, gateways
- 1. Demonstration Workshops
- 2. Installation Training
- 3. On-Line Support
- 4. Periodic Updating Workshops
- 5. Looking to the Future
- 2. Installation Training
h) Miscellaneous system settings
These will include the host operator's node, charge band information, currency names and conversions, simple tax rates, user-group information, and so forth.
i) Processing
One of the following routes will be chosen:
* updating of transaction history and user balances should be separated from invoice processing so that invoices can be completely printed and reviewed by the operator before transactions are recorded and balances updated.
* a system with easy invoice deletion or re-issue for corrections. It should reissue with a different number and new date usually, so that invoice numbering still stays in chronological order. This requires that the system keeps track of whether a particluar month/user has been issued or not. Deleting an invoice should be accompanied by a warning not to do this unless you have the copy of the invoice in your hands and are about to destroy it.
j) Coping with hyperinflation. There will be a facility to run regularly which will adjust all past due balances in a particular currency by a percentage to compensate for inflation. This can work in the form of a set (configurable) percentage per month 'charge' on overdue amounts. It will normally be a monthly routine, to be run just before the next invoicing, but can be adjusted to run more often if necessary. The percentage is an attribute of the currency, and can be set for each currency in use.
k) Year-end functions to produce annual reports, close off datafiles and bring forward opening balances for the new year. The previous year should still be accessible (will be needed for copy invoices and statements, etc.) We should investigate with the likely volumes we are designing this for whether annual closing is enough, or whether it should be (optionally) more frequent to keep the datafiles to a reasonable size. Suggest storing different years/months in different subdirectories to facilitate manual archiving by compressing or removing from the hard disk of older data. This will also make it relatively simple to ask the system to let you view older data. There should be constraints on editing or changing data other than the current set.
3. General system features.
It will use a menu-driven interface:
i) On-line context-sensitive help available at all times by pressing the same key, producing assistance relevant to the current task and pointers to 'further reading'.
ii) All fields which require input of a code (for example, user group) are marked, and a picking-list of possibilities with descriptions is displayed.
iii) All input is checked: undefined codes, invalid dates and improper numbers are rejected with an explanation.
iv) All menus and user input forms are stored in a separate file, simplifying the process of producing versions in several languages.
v) Password control is optional.
vi) The user may quit from any point. The level of system "fussiness" (as in "Are you sure you want to...)" is definable; if passwords are implemented, each user may set their own level of "fussiness".
4. Specification of Data File Importation
1. This should be a sub-menu off the main system menu
2. It should contain pre-defined input formats for:
MsgTrack APC fax and gateway data
3. It should provide for the definition by the operator of new formats. The process could be:
- display first 10 lines of new data file;
- ask operator what delimiter should be used;
- find records with same number of fields that constitute more than about 80% of the file;
- display a sample record of this format;
- starting with the first field, ask the operator to match it with a field required for entry. A list of fields required by the system should be displayed. Data types should be checked automatically, and inconsistencies reported to the operator;
- the operator should be able to save and name this new input format for future use;
4. It should provide testing of data file consistency and integrity.
The system should examine any data file and report to the operator:
4.1 total number of records;
4.2 number of records not matching the format;
4.3 list either total bad records or unique bad records for operator inspection;
4.4 allow operator to prceed with processing, and ignore the bad records, or cancel processing.
5. All account, transaction history and invoice detail information will be in dBase-compatible .DBF files.
6. The host software should have a key configured for exiting into the billing system to facilitate quick checks on the status of any account.
Arni Mikelsons and others, 1992. Technical Report of the Global Networking Workshop, held in Toronto (Canada) 1 to 14 February 1992. Posted on VITA Distribution Service 15 Nov 1992. Filename, available in 3 separate parts as africa_workshop1.txt, africa_workshop2.txt, africa_workshop3.txt.) Total filesize, 135 kB.
Appendix F
Gateway Systems Specifications
Prepared by Viv Kendon, GreenNet, March 1992.
Contents:
Summary
To enable seamless transfer of messages between FidoNet and the Internet/UNIX world, as described in RFCs 822, 1023, and 1036, various changes and enhancements are needed to current gateway systems.
To facilitate better electronic communcations between African FIDO systems and the rest of the computerised world, a reliable gateway is critical. To achieve this, two things are needed:
a) improvements to UNIX-FIDO gateways are needed both for UNIX and DOS platforms;
b) general upgrades to the hosts that support these gateways are needed. This is particularly important at GreenNet to enable it to act efficiently as a major link to APC, Internet and other services for the African hosts.
History and current situation of FIDO - APC gateways
The first APC-FIDO gateways used UFGATE and a separate FIDO node on an AT in the same office as the APC node. The uucp was done over a direct serial line from the AT to the APC node. There were a number or problems with this setup including:
- uucp was slow so the FIDO node was 'off-line' for long periods of time and less available to incoming calls. Moreover, it regularly caused the multi-port serial card to hang completely on GreenNet necessitating a switch to a dumb serial port at reduced speeds.
- format of the To: and Cc: lines embedded in the message text was very susceptible to errors, resulting in delayed messages and a heavy load of support work for the node staff. In an attempt to fix this, tools were developed - fixaddr and gethost - to allow Fido's To: and From: fields to contain internet addresses. These tools were reasonably robust, but occasionally caused problems. Technical staff at Nirv Centre have been enhancing them and subsequently, a public domain programme has appeared with similar functionality and the ability to format the message body to 80 characters per line maximum.
- UFGATE was structured to route all mail from APC systems through the zonegate in Johannesburg, ie. it would not send it directly to African hosts. Sometimes messages would not get through and, at the time, nodes preferred not getting their mail from South Africa for political reasons. A programme called dezone was written to allow GreenNet to route messages to African systems directly.
- A programme called Split must be run to reduce large APC postings and mail down to the 16K maximum for some fido systems. 30K is possible if you know the system receiving is using a capable packer and message editor. This programme also increases the downtime of the gateway machine.
- UFGATE does not support APC style addressing (system:userid) and fax routing.
- running UFGATE requires its own high speed modem and phone line separate from the APC node.
Despite these drawbacks, Pegasus, Web, and NordNet are all running some variation of this set-up based on UFGATE. Compared to other similar available programmes, it is still the simplest 'out of the box' installation for a functional gateway.
Other options were also explored. One was to try and run the FIDO node on the APC UNIX host under a DOS emulation called VPix. The following problems were encountered:
For these reasons, VPix is no longer used.
The current gateway at GreenNet uses RFMAIL under UNIX. However, RFMAIL lacks several critical functions so a DOS based AT node is still required. As described below in "Work Needed on RFMAIL", it certainly works better than previous versions, but a lot of the improvement is due to updated FIDO node software combinations.
One problem not due to RFMAIL's lack of functionality is low data transfer rates over modem connections between GNFido and GreenNet. The transfer rate is fine going gn->gnfido (900cps), but doesn't work the other way. This could be overcome with a bit more testing of serial ports and the resources to try other options.
A newly released version of RFMAIL claims to correct several deficiencies identified, above, however extensive testing is required.
Justification/Motivation
A system that is acting as a gateway between African FIDO systems and UNIX systems must be flexible to cope best with the infrastructural limitations encountered in Africa.
The Internet RFC822/1023/1036 mail/news format is the predominant networking technology of the world today, and will remain so for some time. But, especially in the developing world, MS-DOS is used to the effective exclusion of other operating systems. Networkers' general goals should be to meet the needs and environments of the users, and not try to introduce new and expensive tools which would require extensive training, and ongoing support.
Given smooth gateways between the two types of systems, the FidoNet DOS- based entry-level approach provides the beginning of a smooth evolutionary migration path which might be followed from DOS/FidoNet through DOS/uucp, UNIX uucp, to eventual full use of the Internet Protocol (IP) suite on high-speed leased lines, when these become locally available, which would allow allowing interconnectivity between systems on any levels of this path.
a) Improvements to FIDO - UNIX gateways
Many African host operators will require both a DOS-based gateway on their systems and a remote UNIX-based gateway. The two choices have different advantages.
i) A DOS-based gateway is best for links to local uucp sites (low cost route) such as a university which are usually unwilling or unable to run a UNIX-based gateway to FIDO.
ii) A UNIX-based gateway is best for links to northern systems (high cost routes) to make maximum use of the efficiency of FIDO protocols over long distances. Running the gateway under UNIX will save the gateway site from running a DOS system in addition to a main UNIX host. The savings from not needing a dedicated AT and phone line and modem are significant for a UNIX host.
Moving FIDO under UNIX also allows resources to be shared for different purposes. Any line used currently for interactive users could also be used by incoming FIDO callers. In this way, low-speed FIDO calls would not tie up a high-speed modem. Smaller APC nodes would only need one high-speed modem that could be used for uucp (to talk to other uucp systems) and FIDO. For larger nodes having 2 or 3 high-speed modems means they could be used for their demanding users, FIDO systems and uucp systems. Most APC hosts have a dedicated X25 link, which will allow FIDO callers to use X28 dialup services as an alternative to direct dial phone calls.
Taking advantage of the multi-tasking available under a UNIX system, mail delivery can be speeded up considerably through eliminating the waiting time for a batched gateway to run what is necessary under DOS.
One considerable drawback to running the GreenNet gateway under DOS is that the full complement of APC systems cannot be offered. Under UNIX the full set of APC conferences (about 1000) would be available.
b) Upgrades to International Gateways supporting FIDO
The two APC hosts which currently route electronic messages from Africa to other systems will require several enhancements including:
GreenNet will inevitably be a major gateway to Africa for some time to come given the old colonial patterns of the telephone infrastructure. It is therefore especially important to provide adequate hardware and technical support for the volume of traffic and reliability. The positive benefits for African hosts of these upgrade include:
Why RFMAIL and UFGATE
RFMAIL is a FidoNet implementation of uucp/FidoNet gateway software which runs on most UNIX systems. It implements the relevant standards, is actively maintained by its original author with the help of a number of groups in the networking community, and is freely available, including full source code. It is currently running at GreenNet, IGC Networks, and in South Africa.
UFGATE is the best known and most correct (from the protocol and data format standards viewpoint) DOS-based FidoNet/uucp gateway software. It is widely used, is shareware, and much auxiliary software has been developed for use with it. It is in use on the APC networks today at Web, Pegasus, and NordNet, and needs minimal enhancements to make it quite suitable for the next few years. A future use of UFGATE could be on African FIDO hosts to enable them to connect with local uucp sites, usually university systems.
There are other DOS-based FidoNet/822 packages in development. But, until they are actually released, tested in the field, and shown to be both reliable and compliant with all relevant standards, they should not be used in the high-volume production environment of the APC network or of an African FIDO system. If they are released, field-tested, free and available in source form, they could form the basis of the next generation of DOS-based gateways.
There are also some related DOS uucp implementations such as Waffle, that under the right circumstances may be a good choice to use as part of an overall setup under DOS, and the modular nature of these programs means that they can easily be combined as needed.
RFMAIL and UFGATE thus meet the necessary criteria to form the basis of the gateways that are needed. To be fully functional, with low maintainance requirements, they both need a final 10% of tuning and companion programming.
Work Needed on RFMAIL
RFMAIL and its auxiliary packages need some enhancement. In particular, some of the UNIX support code needs modification to meet the FidoNet standards and to support the special needs of the APC hosts.
The following are necessary additions:
- install a getty/login that will allow a FidoNet system to log in to the UNIX system without any special scripts. At minimum this must be available during FidoNet's Zone Mail Hour (ZMH), but ideally 24 hours per day on the same ports as interactive users. Specifically, the login has to spawn RFMAIL with the proper environment while maintaing a high level of system security.
- RFMAIL's 'fcall' routine needs to have 'session level' passwords implemented to prevent unauthorised FIDO systems from picking up other system's mail.
- RFMAIL needs to allow calls to special routines at the appropriate points in the mail session to allow environment-specific setting of X25 PAD parameters to optimize handshaking, zmodem transfers, etc., for callers using X25 or X28 dialup instead of ordinary telephone lines.
- enhancements to the routines which do splitting/unsplitting of large messages going to/coming from FIDO to comply with the limits on message size in the FIDO standards, following the standards laid out for doing this.
- Additional To:/From: address modifications are necessary to handle the following:
- binary file translation to / from FidoNet file attaches.
- an equivalent of FidoNet's 'AreaFix' function is needed to provide automated un/subscription to news conferences. This should be configurable on the 'news' side to allow other systems besides APC to use this feature, and it should also include different security/access levels configurable on a per node and per conference basis to restrict access to private conferences.
- for proper RFC822/1023 header support and full flexibility in uucp and Internet routing, APC nodes need to convert to a smart mailer such as Smail 3.1. This will require significant technical staff time to do the installation and training, but will provide a much more flexible and supportable environment.
- upgrading to a smart mailer will also handle the necessary mail redirection based on user name which readdresses messages to FidoNet points, FidoNet nodes, and other FQDN Internet addresses.
- compression methods for news and mail should be configurable on a per- node basis as they are under most DOS FIDO mailers.
- refinements to the logging of messages to ensure we have all the necessary information for billing purposes, and processing routines to convert the logs to our billing format on a monthly basis, and mail the processed logs to the nodes that need them for their billing. This is essential if we are to respond to the demand to open up services like fax, telex, dasnet to FIDO users. (The smart mailer can take care of blocking unauthorised users from using these services.)
- documentation for installation, configuration, training, and use in addition to and consolidation of what already exists, including an operator's guide, online manual for all commands (called UNIX 'man' pages), and a full installation guide.
- small programs must be written to convert FidoNet point lists to APC user lists and vice versa, and be set up to run automatically on a regular basis.
Work Needed on UFGATE
UFGATE needs modification and enhancement of its auxiliary programs to meet the FidoNet standards and to support the special needs of the APC hosts.
- some changes for address modification (also called munging) and translation to accomodate the following: - the full range of legal RFC822/1023 addresses (e.g. comments in address fields); - APC node name abbreviations for proper FQDN addresses; - special characters in people's names; - full compatibility with the UNIX-based gateway software.
- binary file inclusion translation to/from FidoNet file attaches.
- small programs must be written to convert FidoNet point lists to APC user lists and vice versa and be set up to run automatically on a regular basis.
- enhancements to the logging procedures to record message size and size of any attached files.
- small programs are needed to control batching and compressing of outbound news and inbound and outbound mail.
Work needed on APC nodes
As noted above, the APC international gateways will need undertake the following upgrades:
A direct Internet connection at GreenNet is essential. For structural reasons (local phone calls are not free in the UK and they are in Canada) Web has already been able to install an Internet link, but installation costs in the United Kingdom are much higher. However, once the initial costs are met, the Internet connection should save enough money to cover the ongoing running costs after one year of operation. Total requirements for GreenNet's connection include:
- Registration and installation fees for leased line and joining the UKNet Internet group;
- Subscription fees for up to one year, after which the ongoing costs can be covered by using the Internet for APC's general message transfer);
- Additional hardware specifically for the link (CISCO router, ethernet);
- Technical staff and consultancy for installation and training.
As already noted, the GreenNet FIDO gateway carries a much higher volume of traffic than other APC FIDO gateways, and this is likely to continue for some time to come. To ensure that this volume of traffic, together with the full Internet connection, can be reliably operated and maintained, a second 486 should be installed in parallel to the current system linked by ethernet so that the load can be shared across two CPU's when the bulk of gnfido's traffic is transfered to UNIX under RFMAIL.
Appendix G
Documentation Work Plan
Prepared by: Karen Banks, March, 1992
CONTENTS
Overview User Documentation History and current status of user documentation Fdguide.txt description Development of user documentation Host Documentation History and current status of host documentation Development of host documentation Development Time FrameOverview
Documentation of ELF (Easy Link to Fido) was identified at the Global Networking Workshop as crucial in the development of electronic communications in Africa. The need for information and instructions in a user friendly format is vital to contributing towards local sustainability of host and user systems. It should:
The documentation should take the reader through an introduction of electronic mail and networking in its many contexts, offering assistance with installation and descriptions of the various programmes used in the software and, most of all, present clear and precise operational guidance for a new user or host operator.
User Documentation
a) History and current status of user documentation
Initially the documentation distributed to new users consisted of various text files written by Mike Jensen which were included in the floppy disk distribution of the Front Door Menuing (FDM) system. See the software discussion for information on the differences between FDM and ELF. The documentation accompanying FDM was:
As the FIDO/APC network developed, additional documentation was written and incorporated into the floppy disk distribution. These included:
b) Fdguide.txt description
Fdguide.txt is a comprehensive guide to Front Door written in French and English. It includes sections on electronic mail, other programmes within the floppy distribution such as an alternative editor, conference manager etc. and reference guides to function keys. The following is an overview of the major areas covered by the document:
All of the files mentioned above are included on disk with all distributions. It should be noted that this documentation was incorporated in addition to any official electronic (on disk) manuals which accompanied the software components of the distribution. The documentation cited above was developed in response to the growth of the network and the need for less technical versions of the official programme documentation.
Most of the work on documentation to date has been done by system operators and trainers already over-extended by technical, training and 'in the field' commitments. It has served, along with on-line support, new users in several African countries (and to a lesser extent users in Europe and Asia) to the point that there now exists the backbone of operating nodes with associated users in Africa which will be able to support a long term, locally sustainable network.
However, what is now needed is documentation that is edited and produced by professional, non-technical staff designed to support the ongoing growth of the network.
c) Development of user documentation
The Global Networking Workshop participants decided that the new documentation should be based on the existing documentation, but should incorporate several major conceptual changes and modifications including:
* a professional DTP level of production;
* translations into French and Arabic;
* an orientation towards a more "hand-held" approach using visual aids eg. screen captures co-ordinated with any electronic on-line help available in the programme, graphic depictions of the route electronic mail takes from the PC to modem and along various gateways to its destination, etc.
A new manual, based on elements of Fdguide.txt, should include the following sections:
* Introduction: Overview of Electronic Communications
- what is an electronic network and how can it help the user
network more effectively with special reference to the
African context;
- description of the APC and it's associated networks (from
outline.txt);
- description of the other services available to email users
eg. fax and telex;
- map of FIDO/APC connections/gateways (from poll.txt);
- description of other electronic networks eg APC, Internet,
Bitnet etc
- different addressing formats eg. APC/Fido/Internet/Bitnet
* System Overview
- how different components work together and why are they
being used (including diagrams and graphics)
- complete accompanying documentation for each component of
the programme (editor, mailer, tosser/scanner, etc)
- batch file and menu system use
* Installation of ELF for a new user
- step-by-step guide to installing your own software and
configuring the system to suit your own needs
* Addressing/Users
- how to read your 'address lists' (Nodelist/point list),
including non-fido address lists
* Description of Editor
- reading messages
- replying to a message
- creating a new message
- altering a message: address, subject, status, content
- importing text files into a message
- creating file attach messages
- creating compressed file attach messages
* Conferences and conferencing
- what is a conference
- subscribing and unsubscribing to conferences
- maintaining folders and areas to organise conference
material
- writing messages to a conference
* Description of the Mailer
- how to request files while in the mailer
- how to read your mail history
* Appendices
- Quick check-list for beginners
- Glossary of all terms used in the manual and terms which may
come up in electronic mail discussions
- Quick reference card to the function keys used in the editor
and mailer
- Modem and phone trouble shooting guide (including
trouble.txt and oxfam.q&a)
* Complete index
Host Documentation
a) History and current status of host documentation
Currently, host operators are using the existing documentation distributed to users. However, the complexities of operating a host are far in excess of those of users, and additional support has been offered in various other forms:
* official documentation accompanying the various maintenance
components of the current programme suite, eg. Imail, Tosscan,
redirection utilities, message tracker utilities, areafix
managers, etc.
* on-line support from other system operators
* periodical on-site training workshops
b) Development of host documentation
The host software documentation will reflect the complexity of operating a node supporting between 5 and 100 users. In addition to the user documentation, particular attention will be given to the various maintenance procedures necessary for host node operation:
* detailed explanation of electronic networking
* detailed description of the different gateways and systems
- eg. how to connect to a university site with particular
focus on the different address formats
* information about the importance of participating in electronic
system operator support and policy conferences
* extensive troubleshooting guide for user (point) installations
including information covering:
- typical hardware problems experienced, eg. serial port
driver, monitoring disk space;
- amending autoexec.bat and config.sys files where necessary
- connecting modems to the telephone exchange
- making calls with operator assistance
- using existing host PC utilities, eg. mouse, Desqview with
ELF
* a separate and extensive guide to modem operation from trouble
shooting through to successful configuration
* description of the GOFDHOST batch file which drives the host
system, and details of the errorlevels that are returned during
its execution
* separate documentation sections on all of the different
programmes used in ELF
- fossil driver
- mailer
- editor
- message splitter
- message tracker
- redirect utility
- sent message mover and renumbered
- conference manager
- nodelist compiler
- nodelist updater
- archiving tool
* detailed explanation of the Fido routing commands
* description of the cc function in the editor and other advanced
features
* more detailed explanation of conferences (sometimes called
folders or boards) setup, scanning for unread mail, moving
messages between folders, etc.
* additional conference maintenance support, eg. conference
traffic monitoring, utilities for maintaining the conference
message base, eg. purging material, packing and sorting message
base, setting up public and private conferences
* analysis of mailer and conference management logs including
monitoring of data transfer rates, costing of different polls,
etc.
* maintenance, trimming, updating and distribution of point and
nodelists
* operation of accounting software and production of bills for
users
As proposed under Host Software, there would be two "host upgrades". The
first would run on basically the same programmes as the user software,
remain free of charge, but would include host specific programmes such
as tracking and billing programmes. The second, the "advanced upgrade"
would include programmes that are quicker, to minimise downtime, and
which hold up better under heavy usage.
In addition to the host documentation that must be created, most of the programmes used include documentation. This is often very technical in nature, but for a host operator, these documents are necessary. Also included with every installation is a document called Policy 4, which is the Fido policy document.
Development Time Frame
The documentation, for both ELF and the host upgrades, will be developed in conjunction with the timeline of the software development plan. See Appendix X.
The documentation will be developed in two stages.
Medium term (3- 6 months)
Using the structure of the current documentation, documents will be written to accompany the release of the test versions of ELF to system operators in the field who will help evaluate both the user and host software.
Long term (6 - 18 months)
Full documentation will bein with the test release of ELF (User software). The documentation process will also provide a period of thorough debugging and testing as the decumentors work their way through all functions of the software.
The release of ELF 1.00 will include thoroughly tested software with completed documentation and will be within 18 months of the beginning of the project.
Translation
The completed documentation will be translated into French and Arabic. The translated documents should be ready with the official release of ELF 1.00. The desktop publishing and production of English, Arabic and French documentation will take approximately 6 weeks.
Appendix H
Training in Electronic Communications in Africa
Prepared for the NGOnet Global Workshop, Toronto Feb 3-7/92 by Doug Rigby, NGOnet (Africa) Coordinator ELCI, Nairobi
In Africa we have developed training for endusers and node operators at four stages; first through an introductory demonstration workshop, second during on site installation, third through on going on-line support and finally by periodic updating workshops.
Demonstration Workshops
Initial interest is often created or renewed by a demonstration workshop which includes discussion of user needs, an illustrated description of what email is and how the networks connect to each other. In the hands- on demonstration, the participants are divided into groups to send and receive messages across the meeting room between two or more computers, modems and phones. While this is often difficult to set up on short notice because of the lack of functioning telephones and the peculiarities of extension phones and PBX systems, it is usually the only thing which convinces new users that this technology really works!
Some of the tools developed for the demonstration workshops in Africa include a two page hand-out in French and English, display material and a computer presentation (prepared by David Schmidt in Nairobi) using story board software. To ensure a good turn out, contact lists, invitations letters and follow-up phone calls or visits are used.
The need to install telephone connections, modems and software in the meeting room provides a not-to-be-missed opportunity to train a small group of potential installers/node operators who have been previously identified. The process on entering a new town is not unlike that of the "Pied Piper" who gathers the townsfolk and whips up enthusiasm to rid the town of "poor and expensive communications". But snake oil salesmanship is not enough. You have to connect the $#%&@ phones and make the software work. Of course your luggage contains internal and external modems, cables, adaptors, software, telephone cables, plugs, soldering iron, line tester, tester phone and an assortment of screw drivers and cutting tools mingled in with the odd shirt and pair of socks. When using borrowed computers, expect that there will be insufficient disk space, an unconnected serial port, incompatible expansion slots or incompatible micro channel architecture. You arrive early and work until you get the system working .. somehow.
Installation Training
On site installation is not unlike setting up for a demonstration workshop. It helps if you have previous information about the kind of phone - direct or dialable extension, local or international, the type and characteristics of the computer, the pinouts of the serial ports or design of the expansion slots.
This represents another opportunity to train potential installers/node operators. You are teaching more than techniques. You are teaching flexibility in approach and positive attitudes to solving on the job problems. You are down on the floor with the recruits sorting out where the telephone cable is connected and inside the computer (with rubber gloves, please) hopefully not dropping the expansion slot cover screw onto the motherboard. It is also an opportunity for recruits to install and configure the software and a time to teach respect for the existing configuration of the computer by making backup copies and seeking permission to modify system files (config.sys and autoexec.bat), files and subdirectories.
The end user training which completes on site installation is focused on sending and receiving messages and files. If two or more users are being set up in the same week, it is good to arrange for them to practise together. The bottom line is for the user to be able to contact an experienced user or the nearest node operator for on-line support. If the node is operating a help conference, additional configuration and training needs to be done so that the enduser knows how to send and receive message within this conference. A previous discussion of needs with the user will determine what additional configuration and training is required. This may include connection to overseas colleagues, participation in one or more conferences or access to specific databases if available. Usually these needs have to be met in stages with additional on site training sessions unless it coincides with an updating workshop.
On-Line Support
This kind of support is the most time consuming of all the training activities since it never ends. It begins with monitoring the new user's activity. There are many reasons for going off line. The telephone or computer "goes down" - sometime indefinitely. More often, it is in relation to doing something new or to recall something that has been forgotten since the initial installation.
In performing this task the attitude of the node operator is critical. A snarly "I'm too busy (even though true) response or a "I have explained that three times already" tone is sure to reduce the number of on-line or voice telephone requests but it will also effectively discourage new users who are usually already embarrassed in having to ask. Viv and Mikej are our role models here. They have over the last two years consistently given prompt relevant support in a non threatening way. Among new users are those who want to know and do everything right away. In responding to this challenge you will find among them the core of a support group who can take on part of the burden of on-line support. A node operator is not expected to know everything but have his/her own on lines of support through which an answer can be found and relayed promptly.
A help conference is the most efficient way to offer on line support since solutions to specific questions can be shared with other users. This is the raw material out of which will arise a users manual entitled "All the Questions you Were Afraid to Ask". It also represents a way that your more experienced users can answer some of the questions and thus lessen the burden on the node operator.
An email users support group/forum now formed in several African cities which bridges NGO, university and governmental organizations (strictly non commercial) provides a potentially democratic mechanism for orienting email training programs that reflect real needs.
Periodic Updating Workshops
Half day and full day enduser workshops are an effective way to impart new techniques and recall old ones. The best ratio of computers to users is one to one because the learning is truly "hands on" but this is rarely possible in Africa. A classroom with 10 386s in a residential setting in Nairobi is the sort of facility which is needed for groups of 20 participants. If anyone knows how to make FrontDoor respond to "hard" wiring rather than to the ring of the telephone, you will save us a lot of money in PBX installation and rental costs.
Most of the curriculum, techniques and teaching materials for enduser training has been developed out of a series of five day workshops for potential node operators in five African cities in the past year with joint funding from several IDRC supported email research projects. The basic content of the course was developed by myself for the PADISnet workshop in Addis Ababa in Feb '91. It consisted of a series of "chalk and talk" presentations to the whole group followed by small group demonstrations. The topics covered included the making of a telephone cable for African phones (not your standard RJ11), installing internal and external modems, basic DOS commands and simple DOS batch files (surprising how few people know DOS) and the installation and configuration of several kinds of communications software such as MTE/Procomm and FrontDoor/SeaDog. Practise in using the software focused on the sending and receiving of messages and files although conferencing and off line database searching was briefly touched on.
At a joint ESAnet/NGOnet workshop in Harare in May we learned what happens when you combine the upgrading of software with hands on teaching. Training notes and exercises go out the window when new software, new versions and new batch files are introduced. The confusion among participants and instructors suggest that we never again hold a workshop in which software changes are made in the night and installed for teaching on successive mornings.
If fact it really makes very little sense to invest in multi language training materials - so desperately needed - if the software packages are going to be changed every six months. Let us agree on a set of software and batch files (which is paid for/shareware or available without cost for non commercial use - let's stop breaking copywrite laws) to be exclusively installed for the next fifteen months across Africa. Let us develop comprehensive multi language training material based on this agreement.
By all means keep testing, experimenting and developing a new package -but hold it off the African "market" until the pre agreed time allowing beta testing and a new round of training materials to be developed. Most node operators are very glad to be part of the Beta testing and on a personal basis are glad to receive new software from the visiting systems developers.
In June in Accra a series of exercises paralleling the teaching notes and small group demonstrations was added and a certificate awarded to those who successfully completed these. The purpose was to consolidate learning through individual hands on practice. It worked! Do you know why?
In Dakar, the Ghana type training program was done in the mornings while in the afternoons we visited the offices of participating organizations to met the staff and trouble shoot email problems or do new installations. The participants were encouraged to form a users group and take decisions on how the local network should operate.
Looking to the Future
Training will be an important element in rooting enduser and node operator skills firmly in the African continent. At the city level there is a need for a users support group and a small cadre of volunteer installers/on line supporters to support the node operator/trainer. To sustain ongoing training, it is necessary to generate local revenue to pay the node operator a local salary commensurate with his/her computer/information management skills. There is also a need for a pool of loanable modems and related cables. Mango has been experimenting with user fees to cover these costs and can give us some guidance. Others, Mikej and Mark have been developing Dbase applications which allow us to prepare user billing statements. Users are willing to pay for services if the fees are in local currency and the charges are related to actual usage.
At the regional level ie four African regions, there is a need for a technical service organization (TSO) consisting of two trainer/support persons. Funds for this structure need to be raised from the external donor community. This would include not only salaries but a travel budget and workshop expenses for staff to conduct demonstration, installation and updating workshops in all the capital and other major cities within their region on a six month basis over the next two years. Communications subsidies would be needed to provide on-line support to node operators in their respective region.
There is also a need for strong networking links among these regional
teams and APC gateways especially at GreenNet. Increasing demands for
support from GreenNet by this structure need to be met by funding
additional on line support capacity at GreenNet. Overall administration
of the TSOs will require the creation of an administration position
located in London for logistics reasons or in Africa within an
organization able to communicate with dispersed personnel and distribute
equipment and funds efficiently.
| Previous Menu | Home Page | What's New | Search | Country Specific |