g3net is a utility to send arbitrary files as attachments to a fax. This is extremely useful to exchange data with people which are only able to send/receive faxes with a faxmodem, and cannot set up a proper data connection (uucp, kermit, slip/ppp, etc.).

Full sources and an MSDOS executable are available from the author. Since most people would wonder "Why should I use such a thing!", the section MOTIVATION will explain why. Please take off your "computer guru" hat when reading that.

Use of g3net

g3net has two operating modes: Note that the ``fax'' includes a lot of redundancy, so that even if up to 30% of fax lines are lost/corrupted, it is possible to reconstruct the original document. Transferring files with g3net is extremely simple:


Q: Why should one use this complex encoding, when there are better ways to transfer data across two modems, i.e.: A: Consider the typical uses of a fax: A paper FAX is very well suited to the first situation. However other situations probably account for the vast majority of faxes exchanged nowadays. In all these cases, the receiver would greatly benefit from having the document sent in some easy-to-process form, e.g. a file containing the desired data. This is what modems and data network have been designed for, you would say ...

Unfortunately, most people who own a faxmodem cannot set up a proper data interconnection. They happily run their faxmodems connected to a Windows/Macintosh box with the fax-handling package which comes with the modem. To them, UUCP, PPP, RZSZ are just obscure names.

The usefulness of an easy-to-use data-exchanging utility is so strong that several producers try to support it. First of all, the G3 standard includes a ``Binary File Transfer'' capability. None of the Class2 faxmodem that I have tried support this option (maybe they do in Class1 mode, this I don't know).

Some FAX-handling packages (e.g. WinFax PRO, Microsoft FAX in Win95) claim to support transfer of binary files using Class1 modems and probably use a proprietary standard to interpret information.

Requiring special capabilities for the hardware (or driving it in a special way) and using proprietary protocols is the best way to:

At least now, the latter seems to be true for data transfers across faxmodems, although big software companies are known to be able to drive the market wherever they want.

g3net tries to overcome these limitations in two ways:

Error correction is an important feature of g3net. Transfers across faxmodems are subject to errors due to noisy lines, or slow receiving programs which cannot handle incoming data properly, and it is generally time-consuming to request the retransmission of missing data. Hence, files encoded with g3net include enough redundant information (through the use of a (255,192) Reed-Solomon code and various forms of interleaving) to be able to reconstruct the original document even if 30% of fax lines are not received (or some of them are received incorrectly).


There are several applications for g3net:


Typically fax messages include mostly textual information. The ``rendered'' version of these messages have a size of 30..100KB per page, whereas the corresponding ASCII (or RTF, or DOC... ) files are 1-2KB at most. Hence, transmission times can be cut by 15..40 sec/page, with corresponding savings, especially on long distance calls and long documents.


Data sent with g3net can be easily reused at the receiver, since they are in binary format. This is extremely useful for people willing to exchange documents without having to set up some kind of ``networking''


Since g3net enables users to transfer arbitrary files, sensitive data can be sent as encrypted files, with the decryption key transferred separately. E.g. you can send reserved info to somebody's fax server without worrying that indiscrete eyes can watch at them, only the authorized people can read the information.


The ability to transfer binary files in a transparent way enables a number of new applications. We mention only a few of them: Sources compile fine with gcc (djgpp under DOS), and are written to be as platform-independant as possible. It is likely that it can even compile on Apple systems.


This program could not have been written without the availability of a Reed-Solomon implementation ("rs.c") by Phil Karn, Robert Morelos-Zaragoza (robert@spectra.eng.hawaii.edu) and Hari Thirumoorthy (harit@spectra.eng.hawaii.edu). The file "tiff.h" and some details on the structure of TIFF files come from the "libtiff" package by Sam Leffler. The "getopt" implementation comes from the BSD sources. Finally, this program can compile easily under MSDOS thank to the DJGPP compiler (a port of GNU's gcc to MSDOS) by D.J. Delorie. The proper Copyright messages appear in each file which has not been written originally by me. For this package as a whole, the Copyright conditions are specified in "g3net.c". It is basically a BSD-style copyright.
	Luigi Rizzo (rizzo@iet.unipi.it)