Connectivity Providers Database

--------------------------------------------------------------------------- N.B. - Please note that the contact email addresses below may no longer be current. The message is archived here for historical purposes, to help document the evolution of Belize's networking infrastructure. The author of the message, Brian Candler, is no longer in Belize. Please do not contact him with inquiries for more details. For more current information about the University College of Belize, please refer to http://www.ucb.edu.bz/. --------------------------------------------------------------------------- From: Brian Candler <brian@ucb.edu.bz> To: sghuter@psg.com CC: jcnamis@bjc.edu.bz Date: Thu, 3 Aug 1995 15:56:57 -0600 (CST) Hi Steve, UCB runs a uucp E-mail node which gets its feed from PSG. In turn we service around 80 other uucp nodes in Belize, who pay a monthly fee and a per-byte charge to cover the cost of the phonecalls we make. The service has been running since February 94, originally getting our feed from the CUNet node at Puerto Rico (upr2.clu.net) but that proved too unreliable. Belize has a monopoly PTT, Belize Telecommunications Ltd. They are planning to get a 128kbps link to MCI, and set up a server offering dial-in shell, SLIP/PPP and leased-line connections. Although they are aiming to have this operational by the end of August, there is no firm start date and no announcement of pricing. BTL is not known for its generous pricing strategy :-) We considered getting our own direct satellite link but apart from the cost, BTL owns the airspace and would charge us a hefty licence fee to run such a link. I have extended my posting in Belize to February 96, and we are in the process of recruiting a trainee to work alongside me. The hope is that by the time I leave, they will be able to maintain the systems without me. > Also - if you have any formal papers or reports you could send - that would > be greatly appreciated. No great shakes here. I wrote a paper last year for a conference on distance education in New Zealand (to be presented by someone else, but I don't know if they ever went). It was done on a Mac but I've attached a text version below. I did attend a conference in Buenos Aires (4th forum on academic networks in Latin America/Caribbean) and prepared a document before I left. This wasn't presented per se but it was available if anyone wanted to know what we were up to. It has some of the technical details about our server, set up using Linux. For someone who came to Belize as a Unix novice, I thought we had achieved some pretty cool stuff; actually it's fairly bog-standard :-) Anyway I've attached that as well. > Date of Entry: 3 Aug 95 > Organization: University College of Belize > Address: P.O.Box 990, Belize City > Country: BELIZE, Central America > Code: No postal code. ISO country code is 'BZ' > Contact Person: Brian Candler (NIC handle BC90) > Voice: +501 2 32732 > Fax: +501 2 30255 > E-mail: brian@ucb.edu.bz > Host/Node Name: ucb.edu.bz (we also route other domain names under .bz) > URLs: No IP connection. There is a Belize-government sponsored page at http://www.belize.com/ > Notes: UUCP E-mail only, via PSGnet Hope this is enough for your needs; get back to me if there's anything else I can let you know. Regards, Brian ---- Brian Candler E-mail: brian@ucb.edu.bz University College of Belize or: brian%ucb.edu.bz@rg.net PO Box 990 Tel: +501 2 32732 Belize City Fax: +501 2 30255 BELIZE, Central America =====<NEW ZEALAND PAPER>===== BELINET: The Belize Information Network K. Mustafa Toure, Development and External Relations Officer; Brian Candler, Computer Specialist; University College of Belize. Introduction In December of 1993, a visit to Belize by Dr Sharon Alexander, Dean of Continuing Education at the University of Montana, prompted a series of discussions on the subject of distance education. As a result, a task force was set up to explore the possibilities of organisations in Belize working together to form a common network for distance education. The network was given the name BELINET, for the Belize Information (or Interactive) Network. Meeting on a fortnightly basis, the initial task force membership of nine persons represented the following public, private and NGO bodies: PRIDE Belize University College Of Belize National Library Service Education Development Centre Belize Tourism Industry Association Channel Broadcasting Cable Company Computers and Communications Consultants After three months of deliberations the task force representatives approved the attached Memorandum Of Understanding (SEE ANNEX 1) for signature by competent authorities of their respective institutions. The task force also set out a number of sub-committees to handle needs assessment, programme content, technical matters and fund- raising/development. UCB Electronic Mail Service One cost-effective and rapid means of sharing information over large distances is Electronic Mail (E-mail). Whilst the BELINET group was being formed, the University College of Belize was already in the process of establishing an E-mail link to the Internet. The "far end" service was provided by the University of Puerto Rico as part of the Organisation of American States' CUNET initiative (Caribbean Universities Network). In fact, UCB had sent a delegate to a CUNET conference in Puerto Rico back in 1991, but it was not until the new VSO computer specialist arrived at UCB that we started to use the service. CUNET provides access to E-mail by means of a dial-up link using uucp protocols (Unix to Unix Copy). This means that CUNET nodes dial in to the University of Puerto Rico periodically, to exchange all outstanding messages in a single burst; this ensures that expensive international phonecall time is kept to a minimum. Puerto Rico has a dedicated line to the Internet, and forwards CUNET E-mail worldwide for free. For the first few weeks, our dial-up was using a standard 2400bps modem, the only one which UCB had. It soon became clear that the cost of transferring mail at this slow speed was going to make the link unviable. The OAS stepped in by donating a new Telebit T1600 modem; this runs at 9600bps, performs data compression, and also has a feature to make the uucp protocol work at maximum speed even over satellite links, where the time delays normally slow the protocol down. This last feature only works when the far end modem is a Telebit also, but this is true at Puerto Rico. The software we used to start with was called Waffle, a bulletin board package which runs under DOS and supports uucp E-mail, and which was also provided by the OAS. The software is relatively straightforward to configure and use. Building an E-mail network However, two problems became apparent: * The cost of making regular phonecalls to Puerto Rico was still going to be prohibitive. At an equivalent of US $1.60 per minute or part minute, calling twice daily could cost around US $100 per month, even transferring very little data, due to the time taken by the modems to negotiate a connection. * Having just a single PC with E-mail service would be inconvenient for the many members of staff at UCB who would want to use it. It was decided that the best way to handle the recurrent costs, and therefore ensure the long-term viability of the link, was to share the costs by making our E-mail service available to other sites in Belize. It would be necessary to have a computer system which could support dial-ins on one or more phone lines, at the same time as E-mail was being used locally by several people. This necessitated something more powerful than Waffle under DOS; we decided that Unix would be a good choice. Most implementations of Unix are expensive, so in the end we settled on Linux, a Unix clone developed by computer enthusiasts. Linux is available at very low cost (US $100 for CD-ROM or 25 floppy disks), and can be freely copied and distributed. The hardware required is a 386 or 486 PC with 4Mb of RAM, which UCB already had. In use, it has proved to be both powerful and reliable; the only problem is its sparse documentation. Within 5 weeks of the dial-in service starting up, our E-mail network had grown to that shown in Figure 1. As well as ensuring the continued operation of UCB's E-mail link, therefore, we had also created a national system for data exchange. By appropriate configuration of the mailer software at UCB and UPR, each site has been given a full Internet address which can be used to receive mail from anywhere on the Internet, and routing via UPR and UCB happens automatically and transparently. Each of the sites which dial into UCB is using the same Waffle software that we used previously to dial into UPR. Each site pays a small monthly fee (US $25) towards running costs, plus the cost of sending and receiving each message over the link to Puerto Rico; the size of each message is logged and itemised invoices generated monthly. In this way, every site benefits by getting Internet E-mail service for a low monthly cost, and without having to make expensive international phonecalls. TABLE 1 BELINET E-mail sites, with Internet addresses (sites located in Belize City unless otherwise indicated) bces.org.bz Belize Center for Environmental Studies bjc.edu.bz Belmopan Junior College (Belmopan) bnpps.gov.bz Belize National Plant Protection Service (San Ignacio) cet.edu.bz Center for Employment Training cframp.gov.bz CARICOM Fisheries Resource Assessment and Management Program icads.org.bz Institute for Central American Development Studies ndacf.org.bz National Drug Abuse Control Foundation nls.gov.bz National Library Service pedp.gov.bz Primary Education Development Project spear.org.bz Society for the Promotion of Education and Research ucb.edu.bz University College of Belize Further Development The most important way in which the network could be improved would be by having a direct, dedicated line to the Internet. Not only would this eliminate the current system of charging for every message sent, but it would open up a whole new range of interactive computer services such as terminal logins and file transfers, which would be of enormous benefit to both teachers and students. Achieving this, though, will be dependent on BTL, the sole telecomms operator in Belize. We are unable to afford the full commercial rate for the leased line, so we are requesting that this link be provided for free or a nominal charge, in the interests of education and national development. The existing dial-up network continues to grow rapidly, however, and a number of other developments are likely: more phone lines and modems; a local area network at UCB to allow access from terminals around the campus; CD-ROM, tape backup, and increased RAM and hard drive storage on the server computer; and setting up secondary server computers in the districts (e.g. in Belmopan, the capital) so that users outside Belize City can enjoy access at local call rates. In addition, the National Library Service is considering setting up a leased line to UCB to facilitate regular exchange of library catalogues, which could form the start of an internet within Belize. Linux provides a springboard by which all these improvements can be made, as and when funds become available. Interactive Audio-Visual Education Although computer networking can play a part in distance education, it is by no means the whole story. The 'live' interaction between teacher and student will probably always remain the most important means of imparting knowledge. The challenge, therefore, is to deliver this at a distance, using video and audio technology. The Jason V Project, which for two weeks in March linked three field sites in Belize by satellite with classrooms around the States and the UK, has created fresh excitement about the possibilities. The BELINET committee (in association with the National Environmental Education Task Force) was able to secure Belizean participation in the project, by setting up UCB as an interactive 'PIN site' for classes of children in Belize to take part. The BELINET technical sub-group ensured that the live programmes were available country-wide, by coordinating the local TV companies in picking up and rebroadcasting the satellite downlink signal; they have also created a video documenting the project, which will continue to be of use long after Jason has left. Such interactive technologies are expensive, however; in a developing country especially, to provide this sort of distance education on an on-going basis it will be important to work together towards a common network, to make most effective use of resources. In addition, it is crucial to assess the needs of people who will be using the system, to ensure that it will be capable of what the educators want to do. BELINET is approaching this on two fronts: * A needs-assessment survey has been carried out, by face-to-face interviews with selected major potential users of distance education: schools and training centres, local businesses, NGOs etc. * A pilot live TV programme is being organised, using the most basic existing technology, to raise awareness and encourage debate about what might be achieved. The TV programme will consist of a linkup between three sites: UCB, the National Drug Abuse Control Foundation (formerly PRIDE Belize), and the studio of Channel Broadcasting Cable Company. All three sites are within Belize City, using the existing cable network of CBC. The distance involved are therefore very small, but the principles would apply equally to a nationwide network. The demonstration will consist of one-way video (from CBC's studio to the other two sites) and three-way audio using conference telephones. As many people as possible from government, business and education will be invited to attend at either of the two receiving sites, and will be able to participate in live discussions. The technology chosen, as well as being simple to set up, is a comfortable "middle ground" between the more advanced forms of linkup, such as two-way digital compressed interactive video, and more basic audio-only systems. By participating in the demonstration, it is hoped that potential users will gain a clearer idea of what these technologies might be capable of. Once the demonstration is over and reactions are gathered, the BELINET group will produce a proposal for a national distance education network and approach funding sources. A number of possible options will need to be considered, for example: * For the long distance links, should we buy time on networks currently under construction by local TV companies, or should we build and maintain our own national network? Our experience with Jason has already shown that we can work alongside local TV stations in the delivery of distance education. * Should we concentrate on getting two-way video links between a small number of distance education centres, or go for simpler one- way video into a larger number of sites (e.g. schools), or some combination of both? Ultimately, the signatories of the BELINET Memorandum of Understanding will need to formalise themselves into a national body responsible for the installation and long-term management of the network. Conclusion The experience of BELINET in Belize has shown that it is possible for organisations in a developing country to work together to develop the resources and infrastructure necessary for distance education. Our electronic mail network was set up for minimal cost and has immediately become financially self-supporting. We believe that our model of cooperation based on a Memorandum of Understanding will enable us to achieve far greater results and make much better use of limited funds and expertise than would be possible for each institution working alone. Our network continues to grow rapidly, so may well have changed by the time this paper is published. Those who would like up-to-date information, or who would be interested in funding further developments, are invited to contact us by Internet E-mail: toure@ucb.edu.bz and brian@ucb.edu.bz or, more conventionally, by fax (+501 2 30255) or telephone (+501 2 32732). Annex 1 The BELINET Memorandum of Understanding "We (the undersigned representatives of our respective organizations) hereby agree to establish a network regarding education, learning and information sharing in Belize with the following goals. IMMEDIATE GOALS 1. The promotion of distance education and the application of communication technologies to education in Belize. 1.1 To identify all parties interested in distance education and information sharing. 1.2 To implement a needs assessment survey for planning purposes. 1.3 To explore several modes of delivery for distance education such as: print, television/video, audio/radio, interactive teleconferencing and computerized electronic mail/on-line information systems. 1.4 To formulate project proposals for the collaborative delivery of BELINET services. 1.5 To forge linkages with other distance education and information sharing networks in Belize, especially the University of the West Indies 'UWIDITE'; the Belize Teachers Training College World Bank project; the National Library Service UNESCO project; and to endorse the University College of Belize 'E-mail' service as a BELINET activity. MANAGEMENT In order to implement this network, representatives of participating organizations shall constitute themselves into a management committee to jointly elaborate, outline and implement all actions arising from the consensus of network member organizations. This general agreement shall become valid from the date of signature by the competent authorities of participating organizations." [Footnote: the "Belinet" group is now inactive; the UCB E-mail system is all that remains. Distance education projects required money... -Brian-] =====<BUENOS AIRES PAPER>===== "BELINET": The Belize Information Network Brian Candler Computer Specialist University College of Belize for the 4th Forum on Academic Networks in Latin American and the Caribbean, Buenos Aires, 14th-18th November 1994 Summary The University College of Belize runs a dial-up UUCP E-mail system, which routes mail from sites in Belize to the Internet, via the CUNET host at the University of Puerto Rico. This paper summaries how we developed this node and made it financially self-supporting, and details some of the technical improvements we have made for more efficient operation, which may be of interest to other system operators. I apologise in advance for its rather piecemeal structure, or rather lack of it, but I hope that someone, somewhere may get some useful tips from it. Our system is based on "Linux", a freeware version of Unix which runs on 386/486 PC compatibles. This software provides us with a fully-fledged mail server which acts as a gateway between dial- up UUCP, Internet protocols such as SMTP and POP over Ethernet and serial lines, and terminal login sessions. We hope to add USENET newsgroups, and ultimately connect with a full IP link to the Internet; for the moment, dial-up UUCP is all that we have. Brief information is included on the PageSat USENET news receiver, which unfortunately only broadcasts to North America at present. It is hoped that the service will be extended to Central and South America in the forthcoming year. History In September 1991, the University College of Belize sent a delegate, Olda Zetina, to a CUNET conference in Puerto Rico. CUNET is the Caribbean Universities Network, set up by the Organisation of American States to promote connectivity in the region, especially for educational institutions. Ms Zetina returned from the conference with the prerequisites for starting a uucp link - some DOS software ("Waffle") to act as a UUCP node, and a password on the CUNET computer at the University of Puerto Rico. However, due to the lack of hardware and the costs involved, this account was never used. I arrived as a VSO volunteer at UCB in August 1993, and found the package left from two years previously. I dug out a 2400bps modem, got the account resurrected at Puerto Rico, and made our first E-mail call on November 4th. It was clear that the link would be far too expensive to run at this slow speed, and so the OAS stepped in to help by donating a Telebit T1600 modem. This modem runs at 9600bps, and has a feature to "spoof" the uucp protocol which is often very slow over long-haul telephone lines (this is explained later). At this stage, E-mail access was only available at a single PC - the one which had Waffle installed - so it was too inconvenient to be widely used by university staff. This problem was solved on two fronts. For outgoing messages I wrote a Pascal program called "Sneakermail" which allowed staff members to write messages on their own PCs, bring them along to the Waffle PC on floppy disk, and import them into the E-mail system (we had no Local Area Network). For incoming messages, I used to simply print them out and post them into the staff pigeonholes, just like receiving a fax. However, the major problem was financial. Phonecalls from Belize to anywhere in the Americas cost $1.60 per minute or part thereof at any time of day or night; even at the higher speed of 9600bps, the $100 (US) per month or more it was costing to call to Puerto Rico once or twice a day was money that the University was simply unable to afford. I decided that the solution was to offer an E-mail service to other sites in Belize, effectively sharing the costs with them. They gain by having international E-mail access at lower cost and without the hassles of managing the international phone link, and UCB gains by having a system which pays for itself (and even makes a small profit). Waffle was designed as a BBS program, and thus included the facility to accept incoming calls and route uucp mail. However, being a single-tasking DOS program, when the system was accessed by a local user it was unavailable for dial-in modem users, and vice versa. You could also have only one phone line. You could attempt to multitask several copies of Waffle under Windows, but Windows is flaky at the best of times so this idea did not appeal to me! I decided that we would need a more powerful E-mail system, in particular one that was capable of multi-tasking, and started to research some possibilities. The ones I came across were Coherent, MK Toolkit, and Linux. Information was difficult to get hold of in Belize, but a friend faxed me a good review of Linux from Unix World magazine, and so that's what I decided to go for. We bought SLS Linux on CD-ROM at $99 + postage. (Incidentally, Coherent is used by Luis Furlan at UVG in Guatemala, E-mail <furlan@uvg.edu.gt>, and he is very happy with it. This may well be simpler to set up and maintain than Linux.) The Current State Our dial-up E-mail service using Linux started in February 1994, and at the time of writing (November 1994) we have over 20 other UUCP nodes in Belize which access our system, each paying $25 per month plus a charge of 1c per 320 bytes for messages sent and received internationally. Our system dials up to UPR four times per day during the week and twice a day at weekends. It has one modem, shortly to be upgraded to two, and also services our local area ethernet running IP (Internet Protocol) for direct access to E-mail from connected PCs. A second Linux computer is also running for students to have direct E-mail access. The OAS has continued to help by providing our main computer with the second modem, a CD-ROM drive, extra RAM, a UPS, and a buffered serial card - all essential for efficient and reliable system operation. Rationale for UUCP operation For those not familiar with the term, "UUCP" is short for "Unix to Unix CoPy" - an E-mail system developed alongside the Unix operating system in the 70s and 80s. With UUCP, computers can dial each other up, exchange a series of E-mail messages in both directions, and then close down the call. Why bother, when you can have a direct IP (Internet Protocol) connection to the Internet? Simply because this requires a dedicated line, which internationally can be prohibitively expensive. $3,500 (US) per month is probably the minimum we could expect to pay for a 64kbps satellite channel to the Internet; in addition we would come across regulatory problems with the monopoly telecommunications company in Belize, BTL. So for the moment, we are stuck with using the telephone system. The benefits of UUCP for exchanging mail are: (a) the calls can be made automatically and without human intervention, at preset times of day. (b) little telephone time is wasted, since the computers exchange mail and then immediately shut down the phonecall. (c) the standard version of the protocol, UUCP-g, provides correction of errors introduced by phone line noise. (d) the protocol is widely implemented for many different platforms and in its basic form is more or less "standard". Although our link to Puerto Rico is UUCP, I did not have to offer the same service to our customers in Belize: I could for example have given them an interactive "login account" on our system, which they would access using a PC terminal program such as "ProComm". However, I decided that for the time being, our users themselves would use UUCP too. This was mainly to minimise the amount of time each user would be connected to the system - with only one phone line initially, if one user were to spend a large amount of time connected and browsing mail, this would block the line from all other users. Phonecalls in Belize are expensive, so this wouldn't be good for the users either. Also, there are a lot of 1200 and 2400bps modems in Belize which don't have built-in error correction, and so UUCP-g allows these to work reliably. The majority of our users have DOS workstations, and so run Waffle, the same as we used to use to access Puerto Rico. One site has a LANtastic network and runs multiple copies of Waffle sharing the same mail directories. There are also two Unix sites; these have UUCP software built-in. Unfortunately, I do not have a reliable UUCP package for the Macintosh. Waffle's internal handling of E-mail and UUCP is fine, but its user interface is decidedly clunky - basically, it uses a command prompt (remember, it was designed as a dial-up BBS). It can be customised a little, for example allowing an external text editor to be called. I would like to develop a more friendly UUCP end- node program, perhaps by modifying an existing mailer such as PC- PINE to act as a UUCP node, but this is a large undertaking. [Footnote: since this paper was written, we are now distributing Pegasus Mail/Wafpeg with Waffle to give a much more powerful and easy-to-use E-mail front end. Macintosh users get UUPC 3.1 and Eudora 1.3.1] Some notes about Linux Linux is a full implementation of the Unix operating system, developed by enthusiasts and provided for free. Companies are not prohibited from selling Linux, as long as they don't restrict you from giving it away to anyone else you like. Therefore, you can install as many copies as you like without getting into copyright problems. As a full implementation of Unix, Linux is very powerful. Some of the features which I use from day to day are: * UUCP * TCP/IP over Ethernet and dial-up lines (SLIP) * Smail, routes and delivers mail messages using UUCP and SMTP * POP (Post Office Protocol) server allows remote PCs to collect their E-mail over the ethernet * ftp server for transferring files between PCs and Unix * telnet logins for remote terminal access * elm and pine for interactive E-mail * bootp server for managing IP number allocation to PCs * programming languages C, awk, sh: I have written E-mail logging and invoicing packages using these, to produce monthly E-mail bills for customers, and to automate repetitive operations such as adding new accounts * shell utilities such as grep and find for locating information on the hard drive * tar, gzip, zip/unzip, uuencode/uudecode for processing packages of files * NFS which we use for sharing files between the main Linux computer and the student machine * And of course, dial-in modem access The system is hugely flexible, and as it is an enthusiast project, all the source code is provided so you can modify it as much as you like. If your modifications are useful, they may be incorporated into future releases of software. As a corollary though, the system is something of a labyrinth to understand, configure and maintain. Some help is given in the form of 'howto' documents, 'faqs' (answers to Frequently Asked Questions), and a 200-page 'Getting Started' guide which you can print out. If you have access to USENET newsgroups, there are groups for discussing Unix in general, and other groups for Linux-specific problems. In my opinion, the system lacks a thorough "Roadmap" of packages, how to use them, and where their configuration files are located. This is something that I will probably have to create myself, since I will be finishing my post here in August 1995 and someone else will need to take over from me. Linux comes in many distributions, including the SLS distribution mentioned before. There were a number of problems with this, particularly with the installation scripts which required various manual patches to be made to the filesystem before things would work (requiring you to become a Unix guru rather rapidly!), and at $99 I think it is overpriced. We have since bought the Trans- Ameritech Linux CD-ROM, which costs only US$30 + $8 postage (see Appendix 1), and this seems much better. We have the issue 3 disk; issue 4 claims to include a number of new features, including the developmental DOSEMU program which lets you run DOS programs under Linux. Details are in Appendix 1. A final note: Linux is not for the faint-hearted. It is often necessary to recompile the kernel (the core of the operating system) to include only those drivers for hardware you have, since drivers for non-existent cards can cause problems at bootup. Although this doesn't require any actual coding, it doesn't do any harm to at know how to compile a program. Try and have a friendly programmer nearby if at all possible! Linux hardware requirements Linux requires a 386 or 486 PC with a minimum of 4MB of RAM. These are the configurations we have at UCB: * Main system: 486SX-25, 8MB RAM, 170MB HD, Mitsumi CD-ROM, SmartUPS 600, Hostess 550 2 (dual 16550A serial card), Telebit T3000 and Telebit T1600 modems, NE2000-compatible Ethernet card * Student system: 386SX-25, 4MB of RAM, 130MB HD, NE2000- compatible Ethernet card The student system proves that it is possible to run Linux on a very basic system indeed, but it really does benefit from having 8MB of RAM instead of 4MB - 'swapping' memory to hard disk is much less frequent, and all spare RAM is automatically allocated as disk cache. The CD-ROM makes software installation much easier, and a UPS is essential to maintain filesystem integrity because if the system is powered off without having been shut down properly, the hard disks can be left in a corrupted state. Communicating at above 9600bps requires a 16550A serial port, which has a built-in FIFO buffer, otherwise incoming characters tend to be dropped when the system is doing other things such as writing to the hard disk. With a 16550A, the computer is now connected to its modem at 38,400bps and this works fine; this allows the modem's built-in data compression to come into play when other sites dial into us. (It doesn't help our calls to Puerto Rico because the batches of E-mail we send are already compressed) Problems with UUCP, and overcoming them with Linux The UUCP protocol, particularly the common 'g' variant, has been around for a long time. It is therefore well tried and tested and pretty robust. In practice, though, there are a number of problems with it. Most of the problems listed below can be fixed by using a completely new protocol - for example, the Taylor uucp package supplied with Linux implements a new 'i' protocol which has several major improvements. However, for the moment this remains a proprietry protocol and so is only of use the two ends both have Taylor uucp installed - which in practice means two Linux nodes. In this case, they choose 'i' as the default over 'g'. 1. It is a 'sliding window' protocol - that is, a certain amount of data can be transmitted without requiring an acknowledgement from the remote end, at which point the transmitter is forced to hold off until some of the previous data is acknowledged. This is fine in itself, and the UUCP-g protocol allows for a maximum window of 7 blocks of 4096 bytes. However, many implementations have much lower limits - in the case of SunOS used at the University of Puerto Rico, it is 3 blocks of 64 bytes. The time to send this amount of data is small in comparison to the round-trip delay through a satellite phone call (or through two satellites, in the case of Belize to Puerto Rico!) and so the data throughput is severely restricted: 190 bytes per second in our original tests with a 9600bps modem. The solutions are: (a) implement the 'g' protocol properly. Usually you have no control over this! (b) use a Telebit modem which 'spoofs' the protocol, producing acknowledgements locally and using a different error-correcting protocol on the phone line itself. This requires a Telebit at BOTH ends of the link. (c) use a different protocol: uucp 'i' has a default window of 16 blocks of 1024 bytes, which can be increased. Since implementations are often limited to poor versions of the 'g' protocol, Telebit modems often provide the only practical solution, and this is the one which CUNET has adopted. We achieve throughputs of 850-950cps in our calls to Puerto Rico. 2. The protocol requires a handshake at the start and end of each file transferred. That is, computer A sends a message to computer B that it wishes to send a file. It won't start until computer B sends a message back saying that this is OK. The file is then send, and at the end computer A requests confirmation that it was received completely; it won't continue until computer B replies. Over a satellite call, this can add up to a lot of wasted time. The problem is compounded by the way UUCP sends E-mail message: they are sent as TWO separate files, a "data" file (D.xxxx) containing the content of the message, and an "execute" file (X.xxxx) containing the instructions where to deliver it. On our calls to Puerto Rico, this was adding up to 7.5 seconds of wasted time for every E-mail message - often much longer than the time taken to send the body of the message itself - and this was reflected in our charging structure to our customers. The solution here is to batch all the messages into a single file. By using a format based on SMTP, the protocol normally used for delivering mail over the Internet, this allows for multiple messages to reside in a single file. The Smail mailer supplied with Linux allows you to do this, and fortunately the computer at UPR uses Smail too - so we are using the same configuration at both ends, and get batching in both directions. At the same time as batching you may as well compress your mail using GZIP (since UUCP quite happily carries binary files, it's not limited to just ASCII text). The final result is that a whole set of E-mail goes as a single, compressed, 'rcsmtp' file instead of separate 'rmail' files, and the throughput is increased dramatically. 3. If a file transfer aborts mid-way, perhaps due to a failure in the phone line, on the next call it has to restart from the beginning. This problem is exacerbated by the batching mentioned above, as you tend to have only one large file to send rather than many small ones. There are extensions to the UUCP protocol to add a restart-from- midway feature, which I understand includes the version of uucp-g released with Unix System V release 4 (SVR4). It is also addressed by Taylor uucp 'i'. 4. The protocol is half-duplex: in the first part of the call computer A transfers messages to computer B, and in the second part computer B transfers messages to computer A. This wastes the phone bandwidth available in the 'reverse' direction, since v32 (9600bps) and v32bis (14400bps) modems are full-duplex, able to transmit at full speed simultaneously in both directions. The only solution here is to radically change the UUCP protocol. The Taylor UUCP 'i' protocol is bi-directional, so files are transferred simultaneously both ways. As you can see, the new protocol is a big improvement over UUCP- g, but won't be of much benefit until adopted widely by implementors of UUCP packges. Cost reductions for the E-mail system So far, we have been able to reduce the costs of sending and receiving E-mail by: * Using Telebit modems - (1) above * Batching and compressing mail - (2) above Further improvements could be made by: * Using faster modems. However, the lines we get from Belize to Puerto Rico don't appear to be able to support 14,400bps operation properly, let alone 28,800bps. * Using a different protocol (UUCP 'i') for bidirectional operation and recovery from file transfer aborts. * Originating calls from the USA, where phone rates are much cheaper - and phone line quality often better. Our ideal development route would therefore be for a UUCP service provider in the USA to make phonecalls directly to our system to exchange mail, using a Linux computer set up for 'rcsmtp' (batched compressed) mail, and a 28,800bps modem. This could potentially cut the cost per byte for E-mail by a factor of five or more. Few service providers in the States are willing to originate calls, however. I wonder if there is a case for setting up an Internet site in the USA as a service provider for countries in Latin America and the Caribbean? The equipment costs would be minimal (one PC with ethernet card, large-ish hard drive, one modem and phone line) and the Linux software would be free, of course. USENET news The above discussion has centered entirely on E-mail. This is of course an important service, allowing you to communicate with other E-mail users, but it doesn't really help you make new contacts and enter public discussions. You can subscribe to mailing lists of course, but much of the Internet's public debate is carried out on the USENET newsgroups. USENET news can be carried over UUCP as 'rnews' batches - groups of messages which have been lumped together and compressed - and over the Internet using NNTP, the Network News Transfer Protocol. Linux (you guessed) can use both of these. Although access to USENET news would greatly enhance the usefulness of our system, we don't receive any newsgroups from UPR because of the phonecall costs involved, and the difficultly of recovering them (unlike E-mail, where you can charge the user for each message sent and received, proportional to its size). There are 40 to 160 megabytes of messages generated on USENET each day, depending on whose estimate you listen to. We could perhaps subscribe selectively to a few newsgroups, but the problem still occurs that if someone posts, say, a 5MB source file or graphic image to a newsgroup, we would be forced to receive it (and pay for the call). Incidentally, I have managed to solve this problem for E-mail messages: the shell script which performs the batching of E-mail at each end of our link, combining all the separate messages into a single file, checks the size of each message as it runs. If it is larger than the threshold limit which has been set, it is truncated to the first hundred lines and a warning message added to the end. We have had a couple of incidents of HUGE E-mail messages being sent to users, which they have to pay for; this problem should now be eliminated. If they really do want to receive a large file it can be broken into segments - something which ftpmail and gophermail do automatically, for example. The ultimate aim, however, will be to get a full IP connection to the Internet - in order to be able to use services such as gopher, World Wide Web and WAIS directly - and this is where our time and energy invested in Linux will really pay off. By using Linux as a server for the various Internet protocols, and setting up the networked PCs as clients, we find we are now ready to connect directly to the Internet. We have already been allocated a Class C network number - that is, all of our PCs have unique IP addresses - so if we had a leased line from here to another Internet node, we would be able to start using it tomorrow. Linux can also act as an IP router, forwarding packets between the local ethernet, other networks over leased lines, and to dial-in modem users, using SLIP - the Serial Line Internet Protocol. This means that we can extend the Internet within Belize, and should not need to invest in expensive dedicated routers (at least initially). Having an permanent IP link will not be the end of development, though, but the start. For people to use these new services we will have to invest in providing more dial-in capabilities with an interactive front-end; work towards establishing "hard links" between UCB and other sites; and of course provide much documentation, training, and outreach. However, we are all increasingly becoming consumers of information, and the potential benefits of wider access to this information are great indeed. Conclusion In the above sections, I have explained (probably in too much detail! :-) some of the rationale behind the way our E-mail system is set up, some of its advantages, some of the technical changes I have implemented to make it more effective, and given some pointers on how we hope to develop the system further. If you would like to discuss any aspect of this, please get in contact with me at the address below: Brian Candler, University College of Belize, P.O.Box 990, Belize City, BELIZE, Central America. E-mail: brian@ucb.edu.bz or brian%ucb.edu.bz@upr2.clu.net Tel: +501 2 32732 Fax: +501 2 30255 If you are interested in helping fund any of these projects, or in setting up institutional linkages with UCB, please contact the Development and External Relations Officer, K. Mustafa Toure (Same postal address and phone/fax; E-mail: toure@ucb.edu.bz) For more information on CUNET, contact the OAS coordinator: Archie_Marshall@umail.umd.edu