Date: Mon, 18 Nov 1996 06:17:00 +0100 (MET) From: Luigi Rizzo <luigi@labinfo.iet.unipi.it> To: hackers@freebsd.org Subject: g3net: sending data over fax lines Message-ID: <199611180517.GAA06284@labinfo.iet.unipi.it>
next in thread | raw e-mail | index | archive | help
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/ ====================================================================
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199611180517.GAA06284>