ftp.wwiv.com/ftp.wwiv.com.zip/ftp.wwiv.com/pub/INTERNET/FXUC03B.ZIP/FXUUCI.DOC

Text File | 1993-08-29 | 19KB | 437 lines

(MS-DOS)                       UUCICO                           (MS-DOS)

FX UUCICO -- Copyright (c) 1993 Jorge Cwik
<[e-mail]>

Version 0.3 beta

I.  INTRODUCTION

FX UUCICO is a drop-in replacement for Waffle's UUCICO. It's fully compatible
with Waffle 1.65, but adds a lot of new features:

o   Up to 115200 bps, and use of the 16550A FIFO (no need for FOSSIL)
o   File restart (crash recovery)
o   File size negotiation and free space management
o   A very robust and efficient protocol 'g' implementation.
o   Smart protocol 'g', with variable packets upto 4096 bytes.
o   A new, extremely fast protocol 'y' for high-speed modems.
o   Protocol 'f' for X.25 or other 7-bits lines.
O   Protocol 'G' for SVR4 systems.
o   Full support for incoming and outgoing grades

Many more new features are being implemented but they are still not available
in this preliminary release.

In all UUCP packages UUCICO is the program who manages the external
communications and file transfers. It's similar to Terminal Programs
(like Telix), except that it performs completely automatically.

Because modems (even the newest) are very slow in computers terms, and
because long distance connections are very expensive, UUCICO performance
is critical.


II.  INSTALLATION.

1) Copy your current UUCICO.EXE to UUCICO.OLD. This is to make sure that
you don't overwrite your original copy. We strongly urge you to take this
step!

2) Copy the FX UUCICO.EXE into your waffle\bin directory.

Because it's designed as a replacement, FX UUCICO will perform perfectly
well without any changes to your WAFFLE environment. The only recommended
changes (not mandatory) are these.

o  Add fx.gpktsize: 1024 to your 'static' file, keep windows
   setting at seven.
   (Only if the system you are connecting supports this size)

o  Unless you have a non-standard hardware setup don't use a
   FOSSIL driver ( change 'uu.driver' in the static file to 'NATIVE').

o  If you have a high-speed modem (over 2400), configure it
   to use hardware flow control (CTS/RTS).

o  If you have an error-correction modem you may want to use
   the new 'y' protocol (change your 'systems' entries in the
   UUCP directory).


Examples:

In your STATIC file...

driver:      fossil
uu.driver:   native
uu.windows:  7
fx.gpktsize: 1024

You may want to make the first tests, without changing any parameters.
FX UUCICO should work right out of the box. Defering the fine-tuning
settings, will help you in finding any particular problem.

III.  IMPLEMENTATION.

FX UUCICO is fully compatible with WAFFLE 1.65, we tried very hard to make
it as transparent as possible. Most messages and logs are exactly the same,
although 'debugging' messages may differ.

There is a potential incompatibility in the waffle/admin/net file. This file
logs all connections and reports xmitted packets. Unfortunately there is no
indication of the amount in bytes or the packet size. This presents a problem
when different packet sizes are used and with protocols that do not use pkts
at all.

We changed the line format of this file to make it more descriptive. Utility
programs that depend on the old/waffle format will probably not work.

Internal 'COMM' driver:
----------------------

The RS-232 driver has been enhanced to avoid the need of FOSSIL in most
cases. It's supports upto 115200 bps, hardware flow control, and will
automatically detect 16550A 'fifo' chips. FIFO mode can be disabled with
the new parameter -z.

When using a FOSSIL driver you MUST set the receiving buffer size larger than
the packet size (/R parameter in the BNU version). The default of 1024 bytes
is not enough for the 'y' protocol. Note that a FOSSIL driver may usually
slow your performance. Most FOSSILs *does not* support bps over 38400. Those
that support them, do it _only_, locking the speed from the command line.
You can still use it (and we recommed you do) for WAFFLE incoming calls
(Awaiting Call).

It's possible that some systems may experiment an erratic behaviour with
the internal driver. Some old RS-232 boards, and some internal modems do
not have a full compatible UART. In those cases a FOSSIL driver (which may
have been tested with these boards) may give better results.

File restart:
------------

FX UUCICO supports file transfer restart, compatible with Unix SVR4 and TAYLOR
UUCP implementations. This is similar to the crash recovery feature in ZMODEM.
You can disable file restart with the new parameter -a.

You may need to temporarily disable the crash recovery option when sending
a file whose name matches an existing file. If UUCP is used to transfer a
file, and the same filename is found in the destination directory, UUCICO
will interpret this as a 'recovery' situation, and APPEND to the existing
file.

Grades:
------

Grades in UUCP links means 'priorities'. By using different grades you can
control which (uucp) jobs are more 'urgent'. Many sites implement this so
they can make better use of the system resources. For instance, mail always
gets assigned Grade 'A' so that it will be sent/received at all hours. But
news may be assigned a Grade of 'B' (or something lower than 'A') so that
newsfeeds only happen during sessions which permit 'B' traffic. Regular file
sends/receives may be Grade 'C' or lower.

All of this allows a site to arrange their traffic so that mail always comes
and goes, but newsfeeds only happen at certain times, and file transfers only
happen in the wee hours of the morning when system usage is lowest.

For more information on grades, see the Waffle documentation or the man page
for Taylor or HDB uucp packages for Unix.

FX UUCICO has full support for grades, and it's compatible with the standard
used in most UNIX UUCP hosts. Grades consist of a single letter attached to
the (uucp) job file name when it is created. They are classified in reverse
ASCII collateral order: 'A' is the highest grade and 'z' is the lowest. Grades
are case sensitive in Unix systems, but they aren't in DOS because DOS doesn't
distinguish cases in filenames.

Calls made by UUCICO use the static file parameter 'uu_grade' and/or the -g
command line parameter for establishing call grade. Calls received by UUCICO
uses the grade requested by the caller. Always the 'caller' (who's probably
paying for the connection) governs the grade. UUCICO will not send jobs that
have low grades than specified, and the remote host is supposed to do the same.
When no grade is specified, all jobs are transferred.

If you does not use grades, WAFFLE will create all jobs with decimal digits
which have an even higher priority. You can still request the remote host for
grade limits. A request for a determinated 'grade' will enable transmission
of any job with the same *or higher* grade.  This is not fully compatible
with Waffle's UUCICO usage, but it is with virtually all common UUCP packages.

Grades are not very useful if the 'caller' doesn't known the remote host conv-
ention. If you implement grades you should tell your users what grades you use
for mail and news.

UUCICO doesn't generate grades, because it doesn't create jobs. Rmail, rnews,
uux and 'uucp' create jobs as specified in the 'mailgrade' and 'newsgrade'
configuration. Note that even though it's not documented, most WAFFLE util-
ities accept a -g parameter to override the grade generation.


File size negotiation:
---------------------

This is an extension to the UUCP protocol introduced by Unix SVR4 and enhanced
by TAYLOR UUCP. Each side tell the others the maximum file size it can accept,
and the exact size in bytes of files before they are transmitted. File sizes
are limited by the Operating System, by the available space on disk and by con-
figuration.

FX UUCICO can be configured for a maximum file size transmission and to leave a
minimum free space on the spool disk. A cooperative party (a remote UUCICO that
uses file sizes) is needed for full implementation.

There are two parameters in the 'static' file for size usage:

    'fx.maxfile'
and
    'fx.freespace'

FX UUCICO will not send files larger that 'maxfile'. It will request the other
side to not send files larger than 'maxfile' or that will leave less than
'freespace' on disk.

If the remote host doesn't understand file size negotiation, FX UUCICO will
still check space on the local site, and reject any files which will leave
less than 'freespace' bytes the local system.

Caveat: Currently FX UUCICO will not do additional checking, once the trans-
mission of a particular file has begun. Future releases will probably check
for disk usage 'on the fly.'

Note that the remote side who is sending a file may react to the 'denying for
size reasons' in different ways. If it's not aware of the 'file size' extensions
it may NEVER send that file again (you may have enough space on disk later).
This is not a failure of FX UUCICO, but simply a feature missing from the host
you communicate with.

If 'fx.freespace' is not present in the configuration file, FX UUCICO will not
check for free space on disk at all (which might improve performance on some
systems). If 'fx.maxfile' is not present the default is 32 Megabytes.


Available protocols:
-------------------

Protocol 'f':

The protocol 'f' is on the original Unix UUCPs. It's designed for 'flow con-
trolled, error correction' 7-bits lines. This protocol is very inefficient for
binary (8-bits) files. It has _no_ internal flow control or error correction.
The only recommended use (and the one it was designed for), is X.25 or other
non 8-bit transparent lines.

Any error during downloads will result in truncating the file to zero length,
this is to avoid invalid data, if file restart is afterwards used. (Note:
aborted downloads with ctrl-c/ctrl-break are not truncated).


Protocol 'y':

This protocol is new. It's extremely fast and efficient. As the 'f' protocol
it was designed for 'error correction' (MNP-V42) modems, but it uses 8-bit
bytes. It's probably the fastest protocol, but you need a 'clean' connection
between both ends.

Most new modems, have hardware error correction. The modems will take care of
flow control and error correction. Note that FX UUCICO has no reliable way to
ensure that an 'error correction' connection has been established. We recom-
mend you 'force' MNP or V42, (see your modem docs).
Because its a streaming protocol (no windows), 'y' it's very efficient on
HALF duplex connections (USR HST and Telebit's PEP/Turbo-PEP).


Protocol 'g':

FX UUCICO supports the full 'g' implementations with variable sized packets up
to 4096 bytes. The error management is very robust and efficient, which should
result in a much better throughput in noisy lines.

Using a large window size (packet size * max windows), makes a big difference
in 'long delay' lines (as in long distance calls), especially in high speed
modems. We do recommend you to use a large packet size, and keep windows at 7.

Because UUCP protocols are used to transfer everything, not just the files,
large packets are inefficient for very small files. This is why variable size
packets are used, only the minimum packet size needed will be used for each
packet.

Unfortunately many old UUCP implementations don't support anything but 3 win-
dows, 64 bytes fixed packets. Some ones are so badly designed that they even
accept other configurations but crash. The -k parameter governs the max packet
size allowed. If the remote host request packet sizes larger than 64, variable
size packets will be used too. Only powers of 2 (from 32 to 4096) are valid:
32, 64, 128, 256, 512, 1024, 2048 & 4096.

Waffle UUCICO supports 128, 256 and 512, but not variable sizes. We note that
many UNIX systems accept 128 (HDB based) and some of them 256. Taylor UUCP
supports the whole range. FX UUCICO is fully compatible with it, and will work
with any configuration. For better results you should yur remote hosts which
use Taylor to implement large packet size and enable short packets.

You _must_ use the -S switch to connect with Waffle Uucico at any packet size
larger than 64 bytes. If you can't connect to a Unix host, reduce the packet
size to 64. Many old implementations will behave in very strangely ways,
when _trying_ to use large sizes.

The default packet timeout was increased to 20 seconds. If you use large pack-
ets and receive calls at low speed, check that the parameter 'uu_delay' is not
too short.

Protocol 'G':

    This is a variation of the 'g' protocol used in SVR4, that is known
to implement the full range of packet sizes. It _doesn't_ use variable sizes,
so it's recommended only for systems which do not support large packets on
the 'g' protocol.


IV.  LOGGING

FX UUCICO creates two different log files: 'uucico' has the normal logging, and
'debug' has all the testing messages and info. This has the advantage of _not_
clobbering the normal log with tons of debugging messages.

Because using high debug levels may create huge files, there is a new parm in
the 'static' file that indicates the drive & subdirectory where the 'debug'
file is written. You may want to put your 'debug' file in a ramdisk, because
otherwise the speed may slow down considerably when using higher debug levels
(8 an up).

   fx.debugdir : [drive:]path

As in other path options, do not put a slash '\' at the end, because one will
automatically added. If this entry is not present, the 'debug' file will be
created in 'waffle\admin' as the usual place for the 'uucico' log. The
optional 'channel' extension is honored and used.


V.   CONFIGURATION

New command lines parameters:

o     -a Disable file restart
o     -z Disable 16550AF usage and detection
o     -S Disable variable packets ('g' protocol only).


New entries in 'static' file:

o     fx.gpktsize: Default and maximum packet size for protocol 'g'.
      (Default to 64 bytes, maximum valid value 4096.)

o     fx.streamtime: Fatal timeout period in seconds for the streaming
      protocols, ('f' and 'y'). Default is 30 seconds.

o     fx.debugdir: Path, include drive and directory where to write the
      'debug' log. Default is 'waffle\admin'.

o     fx.maxfile: Maximum file size in bytes for transmission. Default
      is 32 MegaBytes.

o     fx.freespace: Minimum free space in bytes available on the spool
      drive. Default do not check for free space.

o     fx.backup: Save backups of old jobs in the directory 'spool\lost'.
      Note, backups are never made when file restart is active!
      Boolean. Default is on, make backups.

      Boolean options:
          yes, true, 1 = enabled
          no, false, 0 = disabled

People may want to specify parameters for individual sites, with those
parms valid for that site only. Currently this cannot be done in the
general configuration. To implement such a thing, different static files
or different poll and uushell batch files would be needed. FX UUCICO
does NOT intentionally support such configurations, and users must find
their own way to making such modifications work.

Future releases of FX UUCICO will probably use an alternative configuration.


VI.  TELEBIT modems

TELEBIT are very powerful modems very popular in UUCP hosts. 'Wordlblazer',
the latest model at this moment, is an excellent choice. If both sides are
using FX UUCICO you would be foolish not to use the 'y' protocol, you would
get unbelievable throughput. We reached 2670 cps in compressed news between
two 'Wordblazers'.

Otherwise, you must use 64 bytes packet size to activate the modem 'spoofing'.
Without the spoofing these modems are very slow. The TELEBITs modem will not
spoof if _any_ of both sides requests packets size that are not 64 bytes.
Window size doesn't matter.

In long delay lines (like international calls), it may be better to do one of
these:

   To transmit ascii non-compressed files, use protocol 'f'. If the other side
   supports it, use 4Kb packet; the modems will not spoof, but you may get bet-
   ter performance. If the quality of the line is good, try to connect in V32b
   ('Worldblazers' only).


VII. ALPHA - BETA versions

This is a preliminary version, and in all these cases we recommend you use it
with care. You may wish to back up your system, before installing and running
this version. We recommend you keep a backup of WAFFLE's 'uucico'. The author
of FX UUCICO offers this release AS IS, and takes no responsibility for any
problems incurred through its use.

The 'y' protocol is still in development. It's quite possible that new releases
will introduce changes and modifications that will make the new version of that
protocol incompatible with the current one. Releases from 0.16 and up have int-
ernal version detection and will abort with a descriptive message if they are
incompatible with the version on the other side. In that case use protocol 'g'
(which is an universal standard) to get the new FX Uucico version.

Send comments, suggestions and bug reports to:
Jorge Cwik                 [e-mail]
Horacio Stolovitzky        [e-mail]
US FX Mail List Server     [e-mail]

When reporting a bug, please include pertinent clips from your logfiles, or
any other documentation which may assist us in resolving the problem.
Thanks to all the testers, and specially to Bob Kirkpatrick for their help.


A current copy of the FX UUCICO package may be retrieved from:

US FX Mail Server          [e-mail]

  An empty message to this address will send you the help file
  on return. Additional files and FX documentation are available
  from this server.

FTP Sites:

   oak.oakland.edu     halcyon.com    wsmr-simtel20.army.mil

   File name is currently  FXUC03B.ZIP  (v 0.3 beta)


VIII.   LEGAL

FX UUCICO is (c) copyright 1993 by Jorge Cwik. It is not freeware nor
shareware. This specific beta release is freely distributable by normal
shareware channels, as long as they do not charge for it beyond a nominal
fee for diskette or transmission, and the zip file is not modified in any
way. The author reserves all rights to the software.

As a voluntary alpha-beta tester you are allowed to use this release only
for testing purposes and *limited time* only. We reserve the right to
change both the status and the distribution method in future releases.



We are very grateful to Tom Dell, author of Waffle, for the open
architecture and the vast documentation of Waffle, without which
would be impossible to achieve the compatibility provided by FX UUCICO.
He can be contacted at [e-mail]

All references to WAFFLE are for version 1.65.
WAFFLE is the copyrighted property of Darkside Int'l.