Contents of the BINK_240.DOC file

Addendum to BinkleyTerm Documentation

Changes and Additions for BinkleyTerm Version 2.40

Copyright (C) 1990 Bit Bucket Software, Co.

INTRODUCTION

Rather than update the BinkleyTerm documentation as we have donein the past, we are issuing this addendum file. It is importantthat you read this file thoroughly, as some of the informationherein will supersede what is shown in the manual itself.

By issuing this addendum, the printed versions of the BinkleyTermmanual now in circulation (and still available from Bit BucketSoftware) will continue to be current (except for this addendum). The printed manuals were produced at great expense, and it hastaken us a great deal of time to recoup our expenses. We hope toproduce a printed manual again in the future, but for thisrelease, the BinkleyTerm Version 2.30 docs (printed or otherwise)will remain current with this addendum.

The mailing address for Bit Bucket Software has changed. If youwish to get ahold of us by mail for any reason, our address is:

Bit Bucket Software, Co. P. O. Box 460398 Aurora, CO 80046

Please - do not write for technical support. Support is providedEXCLUSIVELY through the international BINKLEY EchoMailconference. When sending correspondence for other reasons,please include a self-addressed stamped envelope for replies. (Those persons not in the United States should enclose anInternational Postal Reply Coupon.)

PRINTED MANUALS

As mentioned previously, printed BinkleyTerm manuals are stillavailable. Pricing covers the cost of printing, processing yourrequest, and mailing. The prices are as follows:

Within the United States: $15.00 Manual Only $25.00 Manual and Disk

Outside the United States: $25.00 USD Manual Only $35.00 USD Manual and Disk

BinkleyTerm now features an experimental mail transfer protocol called "Janus." It is a bi-directional, full- duplex protocol, and generally requires a full-duplex modem to work properly (USRobotics Courier HST modems, for example, are not full-duplex and cannot use Janus effectively). Under ideal conditions, Janus allows you to transfer mail simultaneously in both directions with Zmodem- like performance.

Due to the depth of the subject, Janus is covered completely in its own section toward the end of the document.

Domain Support

BinkleyTerm now features support for "domain" addressing. Due to the depth of the subject, domain addressing is covered completely in its own section toward the end of this document.

Assumptions

BinkleyTerm supports zone, net and domain assumption. If you have more than one address and different zones, nets, or domains are designated in the configuration file, then BinkleyTerm will use whichever address is appropriate when transacting mail.

For example, net assumption might work as follows. If I have two addresses - 104/36 (primary address) and 1052/1 (secondary address) - and someone calls from net 1052, then my system will identify itself at 1052/1. In all other cases, my system will identify itself as 104/36 (since it's my primary address). The purpose is that your system will identify itself as the most appropriate address depending on the address of the calling system.

File Requests

BinkleyTerm will no longer place calls for a stand-alone .REQ file. In order for a call to be placed, a packet or file attach of the proper flavor must also exist. As always, a manual poll will also allow a call to be placed.

Identical as documented in the manual, except the addition of two more parameters. The parameter designates the reverse video color used in the Pending Outbound window to mark the node you are calling. The parameter designates the color of pop-up windows (such as those produced with the Alt-G and Alt-S commands in Unattended Mode).

Flags

The directory name specified is used by BinkleyTerm to create task identification files. The filename is TASK.# where # is the task number. These files can be used to determine if any given Binkley task is currently running. The file is created whenever Binkley has carrier present and a mail session is in progress.

FTS-0001

When used, this statement will force BinkleyTerm to use only base FidoNet protocol (FTS-0001), effectively enabling the equivalent of the following statements: NoWaZOO, NoResync, NoSLO and NoSEAlink. Used mostly for debugging and testing of FidoNet policy compliance; not for regular use.

JanusBaudJanusOK

Controls whether Janus bi-directional protocol will be used during WaZOO sessions. Please refer to the complete Janus explanation later in this document.

KnownMaxBytes

See 'MaxBytes' for information.

LockBaud []

Works the same as what is documented in the manual, except it now accepts an optional parameter. The parameter tells BinkleyTerm what baud rate at which locking should occur. This is useful for modems that allow a floating baud rate to a certain speed, then are locked at higher connect rates. Most ROM revisions of the USRobotics Courier HST 14.4k model and the USRobotics Courier HST Dual Standard allow this type of operation by setting the modem for &B0 which floats the baud rate at 2400 bps or lower. Bit 7 (and perhaps Bit 6) of the S27 register also need to be set appropriately.

TO LOCK AT 19200 AND FLOAT AT SLOW SPEEDS: Use the 'Baud 19200' and 'LockBaud 4800' statements in your configuration file, and set the modem for &B0 and S27=128.

TO LOCK AT 38400 AND FLOAT AT SLOW SPEEDS: Use the 'Baud 38400' and 'LockBaud 4800' statements in your configuration file, and set the modem for &B0 and S27=192.

MaxBytes

Together with the 'ProtMaxBytes' and 'KnownMaxBytes' statements, you can control file requests by number of bytes sent. These three statements work in the same manner as the other file request limiting statements detailed in the documentation. NOTE: There is a response file "Type 6" response now, which indicates that the caller has exceeded the byte limits.

NoResync

When used, this statement will tell BinkleyTerm not to allow SEAlink Resync (an ability to restart failed SEAlink mail sessions). Used mostly for debugging purposes; not for regular use.

NoSEAlink

When used, this statement will tell BinkleyTerm not to allow SEAlink mail sessions at all, including SEAlink extensions to base FidoNet protocol (FTS-0007) and WaZOO/DietIFNA sessions.

NoZedZap

When used, this statement will tell BinkleyTerm not to allow ZedZap (Zmodem) transfers during a WaZOO session. It is primarily intended to force BinkleyTerm to use DietIFNA mode (SEAlink) during WaZOO sessions. Used mostly for debugging purposes; not for regular use.

ProtMaxBytes

See 'MaxBytes' for information.

ScreenBlank []

Identical in function to what is documented in the manual, but now accepts an optional parameter. The parameter may be "Key" or "Call" and tells BinkleyTerm which method to use to "unblank" the display. "Key" tells it to unblank upon a keypress (and is the default); "Call" tells it to unblank when a call comes in or is placed.

TaskNumber

This statement performs two functions for persons operating in multi-processing or multi-line environments (through a LAN or multi-tasker).

First, it designates a task number for the BinkleyTerm that uses the configuration file that this statement appears inside of. The parameter must be greater than zero (0).

Second, it tells BinkleyTerm to operate in "multi-processor smart mode." If BinkleyTerm is transacting with a particular system, it will create a "xxxxyyyy.BSY" file for that node, named in the conventional packet form (xxxx = net number in hex, yyyy = node number in hex). This file can serve as a flag to other BinkleyTerm tasks, or to compatible mail processing packages so that other tasks or processors will not handle any mail for the particular node until the ".BSY" file is gone. Additionally, BinkleyTerm will not send files to any node for which there is a ".BSY" file.

TermInit

Identical in structure to the 'Init' statement, this statement provides a modem initialization string that BinkleyTerm will use in Terminal Mode. The string will be sent to the modem if BinkleyTerm is initialized in Terminal Mode, or when switched to Terminal Mode from Unattended Mode. The string will also be sent when an Alt-I command is issued in Terminal Mode. NOTE: The 'PreInit' statement, if designated, will NOT be used in conjunction with this initialization string.

SCHEDULING EVENTS CHANGES AND ADDITIONS

Event Exits

Event exits E4-E9 can now be followed by a three character string. If that string is matched in the file extension of a received file, then the designated errorlevel exit will be taken. For example:

When more than one E4-E9 exit applies, the first one is the one taken.

Send Only Events

The "S" event parameter was not documented in the manual. It designates an event which is "send only" meaning that BinkleyTerm will continue to send normally, but will not answer the phone (or if the modem is in auto-answer mode, BinkleyTerm will not respond).

---------SECTION 2 General Reference Information---------

TERMINAL MODE KEYSTROKES CHANGES AND ADDITIONS

Alt-E

Erases the display screen.

Alt-I

Re-initializes the modem.

UNATTENDED MODE KEYSTROKES CHANGES AND ADDITIONS

Alt-G

Allows the generation of an outbound file request. When executed, this command will pop-up a window on the screen where you will be prompted to provide information appropriate to creating a file request. See 'Colors' in "Configuration File" for related information.

Alt-I

Re-initializes the modem (equivalent to Alt-T/Alt-U in previous BinkleyTerm versions). Also causes BinkleyTerm to re-read the outbound mail holding area.

Alt-K

Allows you to kill all mail for a particular node. When executed, you will be prompted for the appropriate information.

Alt-S

Allows the generation of an outbound file attach. When executed, this command will pop-up a window on the screen where you will be prompted to provide information appropriate to creating a file attach. See 'Colors' in "Configuration File" for related information.

In situations where BinkleyTerm would normally release time slice when used in a multi-tasking environment, it will now call the MS-DOS scheduler interrupt (int 28h for the technical among us) when running in a straight DOS environment. This will improve performance of any background tasks like print spoolers and networks.

Mode Switching

When switching from Terminal Mode to Unattended Mode, BinkleyTerm will switch back to using the port shown in the configuration file (if changed while in Terminal Mode).

Multi-Taskers

The PC-MOS operating system is now detected by BinkleyTerm at start-up, and if identified, time slice will be properly released when appropriate by BinkleyTerm to improve overall system performance.

Foreign Language Capabilities

This release of BinkleyTerm allows you to generate your own translations or modifications of much of the BinkleyTerm internal text. Enclosed with this release is a file named ENGLISH.TXT, which is the raw English language text created by the authors, and BINKLEY.LNG which is the compiled binary representation of ENGLISH.TXT for BinkleyTerm's use.

To create your own translation of BinkleyTerm's text strings, copy the ENGLISH.TXT file to a file of your choice for editing. Use a standard ASCII flat text file editor (such as DOS EDLIN or your favorite word processor in non- document mode) to edit the file for your needs. The strings should in most cases be self-explanatory.

When finished editing the file, use the included language compiler, BTLNG.EXE, to compile the text into binary format for BinkleyTerm's use. The command line for BTLNG.EXE is as follows:

BTLNG

For example, to compile the ENGLISH.TXT file, use the following command:

BTLNG ENGLISH.TXT BINKLEY.LNG

The binary language file must be named BINKLEY.LNG in order for BinkleyTerm to recognize it.

Persons who are qualified (bilingual and sufficiently experienced or educated) to translate ENGLISH.TXT into foreign languages are encouraged to do so and to make your translations available to others through appropriate means.

Filtering Negotiation Sequences

In some situations, incoming MNP or V.42 negotiation sequences would cause BinkleyTerm to improperly respond to incoming callers. In this release, BinkleyTerm recognizes the negotiation sequences (if your modem does not filter or use them internally) and will properly discard them.

---------------------------------------------------- DESCRIPTION AND OPERATION OF THE JANUS MAIL PROTOCOL ----------------------------------------------------

NOTE: Janus is an EXPERIMENTAL protocol. It is not at thiswriting a documented FTSC standard. BinkleyTerm 2.40 representsthe first implementation of Janus in a released software product,and is providing its first "real world" testing. With all ofthis in mind, it is important to understand that Bit BucketSoftware cannot and does not provide any assurances or guaranteesthat Janus will work for you in your environment. PLEASE READTHIS SECTION IN ITS ENTIRETY IN ORDER TO UNDERSTAND AND PROPERLYIMPLEMENT JANUS. FAILURE TO DO SO WILL YIELD UNPREDICTABLERESULTS!

An Introduction to Janus

Janus is a file transfer protocol specifically designed for WaZOOmail transfers. It can achieve Zmodem-like performance andreliability, with the major added benefit of being able to dotransfers in both directions simultaneously. It is implementedas dual independent state machines; one for sending files, andone for receiving files. Both state machines run simultaneously,sharing the phone line. All data is exchanged in variable-lengthpackets, with either a 16 or 32 bit CRC. Under ideal conditions,you can expect Zmodem-class performance going both ways at thesame time.

The bottom line is that when two machines exchange mail usingJanus, the smaller of the two nodes' batches of files will besent for free while the larger batch is being sent. If you pollyour EchoMail feed nightly, and usually only send a couple ofkilobytes while picking up a couple hundred, you won't get anyreal benefit from using Janus. But if you normally send 100kband pick-up 200kb, you'll see significant time and money savings.

However, even if you don't usually need to send and receive muchdata at once, and don't get much benefit from the full-duplexfile transfers, you should get Zmodem-level performance even onone-way transfers, and so shouldn't have any penalty for usingJanus rather than ZedZap (Zmodem). The idea is for the benefitsto be there when you need them, without costing you anythingextra if you don't.

What You Should Be Aware Of

There are some important considerations that you should be awareof before using Janus. Most importantly, Janus is a FULL DUPLEXprotocol, and works best with a full-duplex connection. It's nota good idea to try and shove streaming, non-stop, full-duplexdata through a half-duplex connection, since the modems will endup constantly flip-flopping the line around and retraining, andyou'll get terrible performance.

What this means is that normal low speed (1200 and 2400 baud)connections should work fine with Janus, and that high speedlinks that use V.32 should also work fine. High speedconnections with high speed in one direction and a low speed backchannel (such as an HST) will not allow Janus to work well atall.

There are some other situations where Janus will not work verywell. Many systems, modems and networks just don't seem to havethe sustained bandwidth to allow full-duplex streaming data to betransferred accurately.

Telenet's PC Pursuit service is a good example. The service hasgreat difficulty with Janus, frequently dropping and manglingdata. Janus simply saturates the capabilities of the packetswitched connection.

Some modems and even some serial port hardware doesn't seem tobear up very well under the tremendous load Janus can put on themeither. This is probably to be expected, since full-duplexstreaming protocols are rare, and the hardware has probably neverbeen tested under this type of extreme, sustained load.

The bottom line is that Janus may or may not work for you withyour hardware, and if it does work, it may not work well on allconnections. Its implementation in BinkleyTerm has been testedthoroughly, and works very well in many cases. You'll need toenable Janus (by default, Janus is not enabled) and test ityourself in your own environment to know whether Janus is aworkable solution for you.

+--------------------------------------------------------+ | Bit Bucket Software cannot guarantee the performance | | and applicability of Janus. If Janus does not work | | for you in your environment, please do not bombard us | | with questions and comments about the protocol; simply | | disable Janus again (which it is by default). | +--------------------------------------------------------+

Configuring Janus

Your first consideration before using Janus is your FOSSIL driverbuffer configuration. Janus really needs at least a 2kb receivebuffer (or better yet, 3kb) and no more than about a 1kb transmitbuffer (including whatever transmit buffering your modem does). The reason for the large receive buffer may be obvious; thelargest packet Janus ever sends is 2kb, and while it's sending2kb, you can obviously receive 2kb, which Janus won't be able toread from the FOSSIL until it's done sending. So up to 2kb ofdata can easily be received before Janus gets a chance to readany of it, and possibly a bit more in some situations. If yourreceive buffer is too small, you'll constantly lose incoming dataand require massive numbers of retransmissions.

The send buffer should be kept fairly small, because of the waythe packets for the two directions are interleaved on the phonelines. If I'm receiving a large file from you while I'm sendingyou lots of small files, every time I finish sending you a smallfile I have to wait until I've received your entire send buffer'sworth of data before I see the acknowledgement that says youreceived my file okay. If your send buffer is more than 1 or2kb, this can end up wasting a lot of time.

Configuration File Modifications

IF YOU HAVE A LOW SPEED MODEM (2400 baud or under), then you willgenerally use the 'JanusBaud' statement in your configurationfile. Set 'JanusBaud' to your highest supported baud rate.

IF YOU HAVE A HIGH SPEED MODEM (9600 baud or above), then youmight need to use a combination of 'JanusBaud' and 'JanusOK'statements in your configuration file. 'JanusBaud' should be setto the highest FULL DUPLEX baud rate you support. The onlyexception is if you have a multi-standard modem. Use thefollowing as a guideline:

If your high speed modem is single-standard, then 'JanusBaud' isall you will probably need to use. Multi-standard modems require'JanusOK' statement(s) in order to take full advantage of highspeed full duplex (V.32) connections when they occur.

Your multi-standard modem should be set to return extended modemconnect information. This information is appended to the end ofthe modem connect message, and can be used to determine what typeof connection has been made in conjunction with the 'JanusOK'statement.

In the case of a USRobotics HST Dual Standard, you will normallywant to use Janus on V.32 connects, but not on HST connects. Forexample, these connect strings would indicate connections whereJanus can be used:

CONNECT 9600/Arq/V32 CONNECT 9600/V32

But a connection like this would not take advantage of Janus:

CONNECT 9600/Arq/Hst

NOTE: The extended connect information is not shown in all uppercase, since BinkleyTerm will convert everything but the firstcharacter to lower case for display, automatically.

You would permit Janus only on the desired connects, like this:

JanusOK /Arq/V32 JanusOK /V32

Make certain that you also set 'JanusBaud' no higher than 2400,or your 'JanusOK' statements may not have the desired effect. Inaddition, you will probably want to dial out in V.32 mode if youfrequently connect with multi-standard modems of the same makeand model. This will allow Janus to be enabled on the maximumnumber of connections.

NOTE: In testing, it has been found that the "PEP" mode of theTelebit Trailblazer series modems can handle Janus, even thoughPEP mode is not full duplex. Throughput may not be as high as itwould be on a true full duplex connection.

Domain addressing is a relatively new concept in FidoNet, andrepresents an alternative, more complete method of designatingvarious networks than the zone method now commonly in use. Intheory, domain addressing adds an additional "layer" to addressdesignation that represents a particular network. Within thatnetwork, zones and nets can all be specified without conflict toidentical zones and nets in other networks.

Domain support in BinkleyTerm requires you to use separate anddistinct nodelist files for different domains. BinkleyTerm cannow be used much more effectively in multiple networkinstallations, assuming all the elements are configured properly.

'Address' Statement

BinkleyTerm will accept a domain designation in any 'Address'statement in the configuration file. A domain is a validInternet domain in most cases. For example, 1:104/501 might havethe following in its configuration file:

At this writing, FidoNet is the only FidoNet technology networkthat is listed with Internet, but that is subject to change. Alternative networks should be designated by their "common" namefollowed by ".ftn" (for FidoNet technology network). Forexample, a node in Alternet might be designated as follows:

There are several elements to successful domain implementation,in that nodelist and outbound areas change by domain. Thisinformation is given by you in the form of 'Domain' statements inyour configuration file. The format of the 'Domain' statement isas follows:

Domain []

The is the actual domain name. As shown previously,FidoNet would be "fidonet.org" and Alternet would use"alternet.ftn" for the designator.

The is the abbreviated form of the domain name,and is LIMITED TO EIGHT (8) CHARACTERS. This name is passed inthe packet header during a session. In most cases, this will bethe common name of the network, such as "fidonet" or "alternet"in our examples.

Finally, the optional parameter provides the basenodelist name to associate with this domain. If not given, itdefaults to the same name given for the parameter. In our examples, "nodelist" would be used for FidoNet, while"anetlist" would be used for Alternet.

Here are two complete examples of the use of the 'Domain'statement, one for FidoNet, one for Alternet:

NOTE: If you designate a domain in your 'Address' statement,then you must also create a corresponding 'Domain' statement.

Outbound Area Naming

The name of the outbound area also changes according the domain. As always, the outbound area for your primary address (includingdomain) is given with the 'Hold' statement.

Outbound areas for other domains take an identical path, exceptthe name of the last sub-directory is changed to the parameter. For example, if your 'Hold' statementdesignates C:\BINKLEY\OUTBOUND for an outbound holding area (andyou are in FidoNet), Alternet outbound mail would be held in theC:\BINKLEY\ALTERNET.xxx directory instead. Note that outboundareas for domains other than your own will ALWAYS have a zoneextension.

Working Example

If you're thoroughly confused at this point, possibly a workingexample will help. Assume that a configuration file has thefollowing: