FidoNet in Africa (Part 1)

THE EVOLUTION OF A NATIONAL NETWORK ________________________________________________________________________ ________________________________________________________________________ (Part 1)

From FidoNet to Internet: the evolution of a national network

Francois Jacot Guillarmod Computing Centre, Rhodes University Grahamstown, South Africa ccfj@hippo.ru.ac.za

Abstract

--------

The South African academic research network, UNINET-ZA, evolved within two years from a FidoNet mail gateway that distributed email via interactive Kermit links, to a dialup uucp network, to wide area TCP/IP, and finally to full Internet connectivity. While the majority of UNINET-ZA sites are now TCP/IP connected, elements of the original gatewaying techniques are still fulfilling useful functions -- for example a TCP/IP <-> FidoNet gateway, and links into non-Unix, non- TCP/IP based systems.

1. Origins

----------

The academic and research computing environment in South Africa has been influenced by several things:

-the major and minor centres are geographically far apart.

-the distances involved increase the cost of communications infrastructure significantly.

-with few exceptions, the private sector has looked on academia as a limited market that is perenially short of money rather than as potential partners in exploiting technology.

-networking was regarded as something theoretical that happened inside the covers of a text book, or that was carried out by Posts and Telecommunications authorities on behalf of governments.

-the political situation in the country has, until recently, made it difficult to find international organisations willing to co-operate with South Africans.

-sanctions adversely affected the availability and price of hardware and software.

Taken in conjunction, these issues led to a very real sense of isolation and helplessness within the various academic communities. The desire to communicate was there, but the barriers seemed insurmountable.

For the average user, the isolated, stand alone PC was normal, and any communication was via floppy disks sent by airmail or via occasional access to dialup bulletin board systems run by private individuals.

2. First Steps

--------------

A start was made towards wide area networking in 1986, when several universities in the Transvaal linked their systems together in an RSCS/SNA network. This was very much a closed shop in that the participating universities were using IBM equipment, and were geographically close together. These connections allowed for remote login and file transfer, all in an IBM/VM environment.

This axis, consisting of the Universities of the Witwatersrand, Pretoria and Potchefstroom as well as a few research organisations, formed a de facto standard, and, if other universities wanted to get involved in wide area networking, they had to fit in to this environment.

Linking non-IBM computers into an RSCS network involves money and doggedness -- money to purchase the software that will emulate the necessary protocols, and doggedness in dealing with sites that don't believe its possible and are less than enthusiastic about getting involved in such an exercise.

It also requires a certain amount of motivation to convince a university administration that scarce funds and resources should be diverted towards the somewhat dubious benefits of allowing one or two researchers to transfer files to and from IBM systems in another part of the country. In this context, electronic mail and international links became important motivating factors.

The first steps towards breaking the IBM users monopoly on fun and allowing other universities to participate was taken when Rhodes acquired the NJEF package from Control Data South Africa in late 1987. This allowed Rhodes to implement an RSCS emulation on its Cyber mainframes, and the word ``BITNET'' was -- prematurely -- on everyone's lips. The Cybers, running NOS had a locally developed mail system, written in Cobol, which was used to pass notes between users on a single Cyber. This was modified to interface with NJEF, unknowingly and imperfectly duplicating the functionality of the UMass mailer software package.

Initially, communication was limited, and took place between two Cybers in the same computer room. Efforts at linking up to IBM systems in the Transvaal at first proved fruitless and frustrating. More experience was gained when the JNET package was purchased and installed on one of the local DEC Vax systems, allowing it to join in the mini-network of Cybers running IBM protocols.

After some false starts, a link to the IBM network in the Transvaal was achieved with a 2400 baud dialup RSCS connection between Rhodes and Potchefstroom University in 1988. This proved the concept, and the idea of an inter-university network began to be taken seriously. The Foundation for Research Development (FRD) began funding long haul, 64kb digital trunks between universities under the name of the Uninet Project. These high speed trunks were linked to digital multiplexers and allowed point to point circuits to be configured between any two ports on any two multiplexers. The problem of connecting remote sites had been solved.

Simultaneously, investigations were made about the possibility of joining overseas networks, such as BITNET, Janet and uunet. Initial responses indicated that there were no problems on the technical level, but after the University of Cape Town's link to uunet was cut on political grounds, no further negotiations took place. While sympathetic to the idea of communication, nobody could afford to be seen doing business with South Africans or breaking the academic boycott.

A side effect of these negotiations was the discovery that the name ``Uninet'' was far from unique in the world of networking. The bilingual term UNINET-ZA started to be used informally in an attempt at avoiding confusion with the multitude of other uninets.

3. FidoNet

----------

By a fortunate chain of circumstances, FidoNet was mentioned as a possible method for individuals to have access to international email. Initially, this was considered a laughable alternative -- after all, the idea was to provide email access for the masses, and FidoNet was not designed for this purpose. But, as other options disappeared, FidoNet became the only viable method of providing international electronic mail access.

An approach was made to the International FidoNet Association by Randy Bush in Portland, Oregon, and after much internal argument, they agreed to allow South African researchers to use FidoNet to communicate with colleagues in foreign countries, subject to certain restrictions.

FidoNet is a bulletin board system running, for the most part, on IBM PC's owned and operated by private individuals. It can exchange electronic mail, files, and news articles with other Fido systems, using a nodelist to map telephone numbers to FidoNet addresses.

By its nature, a system such as FidoNet assumes that users will log on directly via dialup to the PC running the Fido software and do their processing while running a special interface program to read and reply to mail. This works very well, but access is limited to a few select users with modems, or to those who are prepared to set up their own dedicated Fido systems.

This looked an unlikely mechanism to use for transporting mail between dissimilar networks, but further investigation showed that the FidoNet software followed very well defined standards, and that there were methods for interfacing FidoNet to uucp systems, and thus, indirectly, to the Internet.

Designing and implementing a gateway between the growing RSCS network and FidoNet was the obvious way of stimulating an interest in international email. There were, however, addressing problems to be considered.

A FidoNet user addresses mail to another FidoNet user as, for example:

Dave Wilson at 5:7104/4

and an Internet user can send to a FidoNet user by substituting the relevant Zone, Net and Node information into the following skeleton:

First.Last@fa.nb.zc.fidonet.org

where the various components of the address have the following meanings:

First.Last are the first and last names of the Fido user a is the Fido node number b is the Fido network number c is the Fido zone number

For example, to send a message to Pat Terry at 5:7104/4 from the Internet, the RFC822 domain style address would be:

Pat.Terry@f4.n7104.z5.fidonet.org

The idea was to use this addressing scheme, but, instead of individual FidoNet users, to subvert the ``First.Last'' construct and make it refer instead to ``Username.UninetNode''.

Because UNINET-ZA was based on an RSCS network, the various node names did not contain any domain information -- they were unique in a ``flat'' name space. For example, the address ccfj@rures was unambiguous in the context of UNINET-ZA. So, the FidoNet gateway used a very simple algorithm for dealing with incoming mail from the Internet. Mail addressed to:

ccfj.rures@f4.n7104.z5.fidonet.org

would be delivered to the gateway system at 5:7104/4, at which point the recipients address information would be munged to become:

ccfj@rures}

which ensured that the mail was deliverable, or, at worst, bouncable.

Mail destined for the Internet from within UNINET-ZA was much more easily dealt with. A package called UFgate enables FidoNet systems to exchange uucp mail and news with Unix systems. Appropriately structured FidoNet mail messages can be delivered to such gateways, and injected into a uucp network. All that is required is that the outgoing message be addressed to a Fido node running UFgate, and that the message itself be set up for delivery to a uucp system.

As no Unix systems were available at Rhodes, software to implement the functionality of UFgate was developed both for the Cybers and for DOS. As the Cyber, in true mainframe fashion, was incapable of starting an outgoing terminal session, the PC was used to initiate and control any communication between the two.

%--------------------------------------------------------------------- Figure 1 -- RSCS - FidoNet gateway

%---------------------------------------------------------------------

The gateway was conceptually simple - outgoing messages were accumulated into a so called ``dot separated file'' on the Cyber, and periodically the Fido system would drop into a DOS .bat file that initiated a script driven interactive Kermit type session. This transferred the outgoing mail file from the Cyber to the PC, and any incoming mail from a file on the PC to a file on the Cyber. On completion of the transfer, the PC would munge the outgoing messages into the appropriate UFgate format and place them in a suitable directory where they were indistinguishable from normal Fido type mail messages which could be processed in the normal way. Incoming messages were dealt with by a daemon on the Cyber that separated the messages and then injected them into the RSCS mail system.

While the concept was simple, the implementation was not. Several factors made the production system overly complex:

the CDC NOS operating system does not support ASCII in any useful way, and the most structured language available for writing the gateway software was Fortran 77.

power failures and the vagaries of system maintenance on mainframes made the Kermit style file transfer unreliable, and error recovery mechanisms had to be implemented.

the RFC822 syntax is not easy to parse, so a restricted subset was supported, ensuring long term problems.

The benefits of using a standard form for the transfer of mail -- the ``dot separated file'' -- proved to have several unplanned benefits. It was possible to implement software to process such files at remote sites on several different systems, such as an ADDS Mentor, HP3000, and several different Unix systems.

%----------------------------------------------------------------------- From: barrett@undeed To: some.one@some.domain Date: Mon, 6 Apr 88 23:05:04

first message body

From: pinkham@ucthpx To: local.part@another.domain Date: Mon, 6 Apr 88 23:05:04

second message body

Figure 2 -- dot separated file format

%----------------------------------------------------------------------

Using the widely available Kermit style file transfer mechanism over long distance dial up and X.25 packet switching networks proved surprisingly effective. There were, however, ongoing problems with the error recovery mechanisms -- particularly when transferring large quantities of data -- that were never satisfactorily resolved.

Ignoring the negative aspects, this technique allowed other universities to start exchanging mail with systems in the RSCS network. Feedback from sites that had implemented this mechanism on Unix indicated that there were tools available that could simplify the implementation considerably.

4. Move to Unix and uucp

------------------------

The possibilities and advantages of Unix as a platform for further network development were becoming more and more apparent. Rhodes University was donated a copy of SCO Xenix for evaluation purposes early in 1990, and this caused a re-think as to how networking should be approached in the longer term. Politically, it was still FidoNet or nothing as regards international links, but the capabilities of Unix and uucp could not be ignored as they allowed the use of commonly available utilities and techniques.

The implications of a uucp connection to the U.S.A. were discussed, and, after more argument, resolved in a similar way to the FidoNet link. Restrictions were made as to the type of site that would be allowed to link into any uucp network, and elaborate procedures were implemented for screening and filtering traffic to and from sites affected by the Comprehensive Anti Apartheid Act enacted by the U.S. Congress.

The move to uucp was technically simple, as it could support the flat RSCS name space as well as fully qualified domain names. This versatility allowed both uucp and FidoNet to coexist as mail transports, although there were anomalies as IBM systems, Vaxen and Cybers masqueraded in the uucp maps.