From owner-freebsd-hackers  Sun Nov 17 21:54:59 1996
Return-Path: owner-hackers
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.5/8.7.3) id VAA13395
          for hackers-outgoing; Sun, 17 Nov 1996 21:54:59 -0800 (PST)
Received: from labinfo.iet.unipi.it (labinfo.iet.unipi.it [131.114.9.5])
          by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id VAA13382
          for <hackers@freebsd.org>; Sun, 17 Nov 1996 21:54:44 -0800 (PST)
Received: from localhost (luigi@localhost) by labinfo.iet.unipi.it (8.6.5/8.6.5) id GAA06284 for hackers@freebsd.org; Mon, 18 Nov 1996 06:17:00 +0100
From: Luigi Rizzo <luigi@labinfo.iet.unipi.it>
Message-Id: <199611180517.GAA06284@labinfo.iet.unipi.it>
Subject: g3net: sending data over fax lines
To: hackers@freebsd.org
Date: Mon, 18 Nov 1996 06:17:00 +0100 (MET)
X-Mailer: ELM [version 2.4 PL23]
Content-Type: text
Sender: owner-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

If someone is interested, I have written a relatively simple
encoding/decoding program to send binary data across faxmodems.
Full sources are available at

	http://www.iet.unipi.it/~luigi/g3net.tgz

(beware, a 36-hour development time cannot guarantee against bugs,
and sources are updated frequently).

I use it with mgetty+sendfax, but the program compiles and runs fine
under djgpp, and today I will do some tests with some DOS/Windows fax
packages, so it should really be a cross-platform solution. I'd say you
can think of it as an alternative to UUCP.

The program works as follows:

ENCODER: g3net -f infile -o outfile

    the encoder takes a binary file and produces on output a
    g3-format file (where lines are shorter than 1728 pixels, but
    g3cat takes care of this). The g3 file contains the original
    data protected with a 192,255 Reed Solomon code, and scrambled
    in a coupled of ways to protect from lost lines. Up to about
    30% of lines can be lost without data recovery problems.

    The encoder is intended to be used to build a g3 file which
    can then be sent with faxspool. It is not hard to add a "-raw"
    flag to faxspool to run the encoder automatically.

DECODER: g3net -d -f infile -o outfile

    the decoder takes a received fax (g3 file produced by mgetty)
    and tries to reconstruct the original data applying the reverse
    process, thus unscrambling the data and applying error correction.

    The decoder could be used within "new_fax", or whatever is
    called by mgetty at the end of a successful reception of a fax.
    Decoded data can contain everything, from the source of a fax
    message (usually shorter by a factor of 20 than the rendered
    fax), to binary data (for the fun of it, I downloaded an update
    to the distribution using this method).

KNOWN BUGS:

    The g3 file has lines shorter than 1728 bits. This will be
    fixed in future revisions; anyways, g3net takes care of this
    and produces regular pages.

    Long files gets translated into a loooong fax. Some modems
    accept unlimited size pages, so for them this is not a problem.
    in the future there ought to be a facility to split these faxes
    into shorter pages and reassembling them at the receiver.

APPLICATIONS

Using sources instead of rendered pages for sending a fax shortens
the sending time for two reasons: first, fewer data are sent;
second, fewer fax-pages can be sent.

>From my logs negotiations and handshake take ~10 seconds at
communication setup, plus ~5 sec/page. The typical rendered page
(30KB ?) takes about 25 seconds to sent, whereas the source for
the same data is in the 1-2KB range, taking 2-4 seconds. A 10-page
document can be probably save a few minutes of communication time
(not to mention the quality improvement and the ability to add
automated processing of data).

For data transactions, the whole process of sending a relatively short
(20..100Kb of data) is probably faster by using g3net than loggin into
your system, and either starting ppp/slip or using kermit or some other
file transfer programs.

If someone wants to play a little bit with this, I'd be glad to hear
some feedback, suggestions and bug reports.

	Cheers
	Luigi
====================================================================
Luigi Rizzo                     Dip. di Ingegneria dell'Informazione
email: luigi@iet.unipi.it       Universita' di Pisa
tel: +39-50-568533              via Diotisalvi 2, 56126 PISA (Italy)
fax: +39-50-568522              http://www.iet.unipi.it/~luigi/
====================================================================