Contents and Organization of this FAQ
Q.
Who do I contact concerning BLAST products?
-
Phone Numbers:
-
+44 (0)1728 832712 - Sales or Tech Support
-
+44 (0)1728 830196 - Fax
-
Mailing Address:
Open Communications International Ltd
Colonial House
Leiston, Suffolk
IP16 4JD
ENGLAND
-
E-Mail Addresses:
-
World Wide Web Address:
www.opencomm.co.uk
Q.
How do I interpret the product description? (see Media Codes and
Pricing)
A. 3/486PRO-UNX/XEN-S-10.7,
for example, is interpreted as follows:
3/486PRO (386/486 Professional) = Hardware/Product Name
UNX/XEN (UNIX/XENIX) = Operating System
S (3.5" diskette) = Media Code
10.7 = Version
Q.
How do I interpret product media codes
A. MEDIA CODES (see Product
Description and Pricing)
C = QIC tape
D = 4mm DAT/DDS tape
H = 1600 bpi tape/9 track tape
S = 3.5" diskette
T = 5.25" diskette
E = 150 MB cartridge
K = TK50 tape cartridge
D/S = 4mm DAT/DDS tape & 3.5" diskette
Q.
What is BLASTscript?
A. BLASTscript is a programming
language designed to automate communications tasks. BLASTscript allows:
-
Automation of regularly performed file transfer tasks
-
Unattended polling of remote sites through the supplied
Autopoll script.
-
Automated modem initialization and dialing through the
modems.scr script.
-
Automated logon procedures for many multi-user systems through the
systems.scr script.
BLASTscript provides a variety of commands for tasks like sending and capturing
characters, manipulating files, sending and receiving files, parsing, executing
local and remote system commands, logging, branching and conditional execution.
BLASTscript also provides a variety of reserved variables to allow monitoring
of the status of script execution and to change parameters of a scripting
session.
Q.
I'd like to write a script to automate a communications task. How do I
start?
A. Begin by practicing the
steps manually a few times to familiarize yourself thoroughly with the task.
Then place BLAST in Learn mode and repeat the task again. While in Learn
mode, BLAST will create a script from the actions you take.
Think of this as a rough draft; you will need to add your own comments and
scripting code to handle communications errors and other exceptions.
Q.
What are modems.scr and systems.scr?
A. Modems.scr and systems.scr
are special scripts that automate the logon and dial-out processes in BLAST.
For example, if you enter Unix as the system type and HAYES as the modem
type in a BLAST setup, BLAST will automatically know how to dial out on your
HAYES modem and logon to the remote Unix system. These scripts are automatically
installed by BLAST. They are updated periodically and the latest version
is always available on Blaster and the BLAST anonymous FTP site. There are
specific modems.scr scripts for Unix, DOS, and BHOST, named, modems.scr.uni,
modems.scr.dos, and modems.scr.bho.
Q.
How do I obtain the latest modems.scr and systems.scr?
A. The latest modems.scr and
systems.scr scripts are kept on the BLAST anonymous
FTP site. The script
can be found in the pub/ directory on the anonymous FTP site. On the Blaster
demo line the scripts are in the scripts/ directory.
Q. What
is Autopoll?
A. Autopoll is a data collection
and distribution script designed to dial from one to thousands of sites and
perform reliable, automated transfer of data.
-
Autopoll is easy to modify. Autopoll can be used out of the box or as a template
to build a customized polling system. It is written in BLAST's scripting
language and is fully commented.
-
Autopoll is designed for hands-off operation. It requires no operator
intervention.
-
Autopoll is easy to configure. An Autopoll network can be configured by creating
just two text files: a site file and a transfer command file. A site file
contains connection information for sites to be dialed. The transfer command
file instructs BLAST on actions to be taken during a connection.
-
Autopoll checks for errors while polling. If a problem occurs during a
communication session, Autopoll will automatically schedule to redial the
problem site.
-
Autopoll creates an audit trail of transfers. If problems occur in the polling
process, staff can easily determine where the problem occurred.
-
Autopoll is supplied with all supported BLAST products.
Q.
How do I configure Autopoll?
A. Check out the autodocs.txt
file supplied with autopoll. It is also
available on the BLAST
anonymous
FTP site.
Q.
How do I obtain the latest Autopoll?
A. The latest autopoll scripts
are kept on the BLAST anonymous
FTP site. The autopoll
scripts can be found in the dist/scripts/autopoll/ directory on the anonymous
FTP site. On the Blaster demo line the scripts are in the scripts/autopoll
directory.
Q. What
is the BLAST Protocol?
A. Development of the BLAST
protocol began in the mid 1970s. The BLAST protocol is
sliding window protocol. It is designed to
work over 7-bit and 8-bit connections and provide complete transparency for
control characters. Therefore, it is compatible with both
software and
hardware flow control. The BLAST protocol
uses a 16-bit CRC for error detection.
Packet sizes can be set by the user from 84 bytes to
4084 bytes to maximize performance.
The BLAST protocol is more than a file transfer protocol. The BLAST protocol
should be considered an error-free session protocol. BLAST is capable of
transferring files and manipulating files on the remote machine. All file
operations occur within the error-free BLAST session. It is not necessary
to know the specific instructions for a particular operating system. BLAST
automatically translates commands into the appropriate instruction for the
remote system.
File Transfer Features:
-
Send Files
-
Receive Files
-
Send and Receive files simultaneously
-
Set file permissions and ownership during file transfer
-
Restart an interrupted file transfer from the point-of-interruption
-
Multiple levels of file compression during transfer
-
Text translation between systems
-
File overwrite
-
File append
File Manipulation Features:
-
Remote file rename
-
Remote file delete
-
Remote file printing
-
Remote change directory
-
Remote file listing
Tunable parameters
Q. What
is the XMODEM Protocol?
A. The XMODEM protocol was
developed in 1978 by Ward Christensen. The XMODEM protocol detects errors
in transmission through use of either a
checksum on old implementations or through
a cyclical redundancy check (CRC) in later
implementations. XMODEM uses a fixed packet size of
128 bytes and falls into the general category of Half-Duplex
ACK/NAK protocols. It must pause after the transmission of every packet
until it receives either an ACK or a NAK from the remote system. XMODEM has
some significant limitations. For one, XMODEM only works on 8-bit connections.
If you must make connections to devices that have 7-bit data paths, XMODEM
will not work. Secondly, XMODEM must be run with either no
flow control or
hardware (RTS/CTS) flow control. If you attempt to run with
software (XON/XOFF) flow control, your
connection will hang. Thirdly, XMODEM provides no encoding or transparency
for control characters. Thus if you attempt to transmit a binary file using
XMODEM, the transmission is likely to hang if there are any XOFF characters
in the data. Fourthly, XMODEM has no facility for transmitting the name of
the file. You must enter the file name on the receiver side of the transmission.
Finally, XMODEM was written to take advantage of the 128 byte CP/M file system.
XMODEM pads files out to the nearest 128 bytes during transmission. Thus,
it is impossible to retain the original file sizes using XMODEM.
Q. What
is the KERMIT Protocol?
A. The KERMIT protocol was
developed in 1981 at Columbia University and named after Kermit the Frog
of the Muppet show. KERMIT runs over both 7-bit and 8-bit connections and
is transparent to control characters. Due to its ability to run over both
7 and 8 bit connections and transparency, KERMIT is a more flexible and reliable
protocol than XMODEM. However, additional overhead
makes KERMIT slower than XMODEM. The original KERMIT is an
ACK/NAK protocol using small but variable length
packet sizes. Newer implementation of KERMIT support
a sliding window protocol and are faster than
the original KERMIT.
Q. What
is the YMODEM Protocol?
A. The YMODEM protocol was
developed in the early 1980's by Chuck Forsberg of Omen Technologies. The
original intent was to make some simple extensions to the XMODEM protocol
to improve performance. YMODEM uses a fixed packet
size of 1024 bytes - 8 times the size of XMODEM.
Even though it is a half-duplex ACK/NAK protocol, it is
significantly faster. Because it uses larger packets,
YMODEM spends much less time waiting for a response from the receiver than
XMODEM. YMODEM also transmits the file name as part of the file transfer
so that it is not necessary to enter a file name of the receiver end of the
transmission. Unlike, XMODEM, YMODEM is capable of transmitting the exact
file size. Otherwise, YMODEM has same limitations as XMODEM.
Q. What
is the YMODEM-G Protocol?
A. YMODEM-G is a variant of
YMODEM. YMODEM-G was designed to provide maximum performance over half-duplex
modems that guaranteed error-free connections. Old, half-duplex modems were
highly efficient at transmitting data in one direction. However, when they
had to "turn-around" the direction of data transmission efficiency was lost.
Thus, ACK/NAK protocols like XMODEM, YMODEM and KERMIT were very slow. YMODEM-G
was designed to get around the limitations of old modems. It does not wait
to receive ACKs or NAKs from the remote system. It streams packets of data
constantly and assumes everything is received correctly. If an error occurs,
the receiver sends an error signal which causes the entire file transfer
to abort. As long as no errors occur in a YMODEM-G transfer there are few
file transfer protocols with better performance. However, modern full-duplex
modems do not suffer the same performance limitations of old half duplex
modems and problems often do occur in filetransfers. Therefore, there is
little advantage to using it.
Q. What
is the ZMODEM Protocol?
A. ZMODEM was designed by Chuck
Forsberg of Omen Technologies in the late 1980s. ZMODEM is a
Sliding window protocol that uses variable
packet sizes. ZMODEM works over both 7-bit and 8-bit connections. ZMODEM
works with both software (XON/XOFF) flow
control and hardware (RTS/CTS) flow
control. ZMODEM also has the capability of restarting a file transmission
from the point of interruption.
Q. What
is FTP?
FTP stands for "File Transfer Protocol." Since its origination in
the early 1970's, FTP has become the de facto standard for file transmission
on TCP networks. FTP was designed to promote sharing of files across
networks while shielding users from variations in how files are
accessed and stored on different computers systems.
Like other file transfer protocols, FTP operates in a client/host fashion.
FTP Client software is used to make a connection to an FTP Server. FTP
client software generally has a user interface designed to facilitate
file transfers and information requests like directory listings. There
is no user interface to the FTP Server. It simply waits for a client
to make a connection, presents a login prompt and fills requests for file
transfers and information. On Unix machines, FTP server software is
known as the FTP daemon or simply FTPd. On NT, an FTP server is
called the FTP Service.
The FTP specification provides for many powerful features. For
example, FTP can provide restart from the point of interruption,
compression, and a variety of text translation functions. Unfortunately,
few servers implement the complete FTP specification. So,
while FTP is a powerful multi-platform file transfer tool, there
are several shortcomings with most implementations of the protocol.
Most FTP clients and servers, including those found in BLAST products, provide
only the "stream transmission mode." When transferring files in stream mode,
the FTP specification requires that the FTP server close the data connection
to indicate the end of file has been reached. Unfortunately, the FTP client
has no way to differentiate between an actual loss of the network
connection during a file transfer and the close of the connection
after a successful transfer. According to the FTP specification - RFC959:
"The stream transfer mode is inherently unreliable,
since one can not determine if the connection closed
prematurely or not."
Therefore, some independent means of ascertaining that
a file has been completely transferred must be used. There
are various methods of determining if the file
was completely transferred. If files are being transferred
interactively, one usually notices that the transfer seemed
rather quick or that the file is rather small. For automated
transfers, packages such as Mirror get a file list from the FTP
server. Then using the scripting capabilities of PERL, Mirror
parses the file sizes out of the listing and compares it
to the number of bytes actually received. If the sizes
match, Mirror assumes the transmission was complete.
Secondly, provisions exist in the FTP specification for restarting
a file transfer from the point of interruption. Few FTP servers and
clients, however, actually implement this feature.
Finally, the FTP specification also has provisions for compressing files.
Once again, however, few FTP servers and clients actually implement
this feature.
Because so few FTP servers implement restart of file transfer from
point of interruption and compression, BLAST's FTP clients do
not support these capabilities.
Q. What
is a Half-Duplex ACK/NAK Protocol?
A. A half duplex, or ACK/NAK,
protocol sends a packet of data and then waits until it receives a response
from the remote computer. The receiving computer will either send an
acknowledgement (ACK) that the data was received correctly. Or the receiver
will send a non-acknowledgment (NAK) if the data was corrupted. Performance
of ACK/NAK protocols suffers due to the fact that they wait for a response
from the remote computer prior to sending the next data packet.
XMODEM and the original KERMIT
protocols are examples of Half-Duplex ACK/NAK protocols.
ACK/NAK protocols should be avoided for use over
packet switched networks. The propagation delays inherent in packet switched
networks will cause extreme performance problems.
Q.
What is a Streaming Protocol?
A. A streaming protocol sends
a continuous stream of packets without waiting for a response. Because there
is no waiting for the remote system to respond, the performance of a streaming
protocol is better than an ACK/NAK protocol. Streaming protocols have no
means of retransmitting corrupted data. They simply abort the transfer if
any data is corrupted. An example of a streaming protocol is YMODEM-G.
Q.
What is a Sliding Window Protocol?
A. A sliding window protocol
is a special type of streaming protocol. Like a
streaming protocol, a sliding window protocol sends a continuous stream of
packets. Unlike a streaming protocol, a sliding window protocol expects to
receive ACKs and NAKS from the receiving system. If the receiver sends a
NAK, the sender will back up and resend the corrupted packet. A sliding window
protocol will provide higher performance than an ACK/NAK
protocol. The BLAST protocol and ZMODEM are examples of sliding windows
protocols.
Q.
What are checksums and CRCs?
A. All file transfer protocols
must contain a method for determining if the data has been corrupted in
transmission. Checksums and Cyclical Redundancy Checks (CRC) are mathematical
checks for ensuring the integrity of data.
A file transfer protocol appends some type of check to the end of each
packet of data. The receiver computes the same check
on the received data. If the checks match, the data is accepted. Otherwise
it must be retransmitted.
A checksum basically adds the values of each byte of data in a packet. Checksums
are only considered reliable with very small packet sizes. As packet sizes
increase, the probability increases that multiple errors can occur and not
be detected.
A CRC is a more complicated calculation. Fortunately, calculating a CRC is
not particularly computationally intensive and CRCs are much more reliable
than checksums. The probability of multiple errors being undetected is
practically zero. The ITU (which used to be known as the CCITT) recommends
use of a 16-bit CRC for file transfer error-detection. BLAST uses a 16-bit
CRC. Explaining how a CRC is calculated is beyond the scope of this FAQ.
However, many lucid and understandable explanations of the mathematics and
how to code CRCs are available in computer science and other programming
texts.
Q. What
is a packet?
A. All file transfer protocols
break a file into pieces of a set length that are then transmitted to the
remote system. These pieces of data along with some housekeeping information
are known as packets. A packet usually has some header information like a
sequence number. Following the header is the actual data being transmitted.
At the end of the packet will be some type of checksum or CRC used by the
remote end to validate the contents of the packet.
Different protocols use different packet sizes.
For example, XMODEM uses a packet length of 128 characters.
YMODEM uses a packet length of 1024 characters. The
BLAST protocol allows the user to set the packet lengths from 84 characters
up to 4084 characters.
Q.
Does packet length matter?
A. Packet length will influence
file transfer speed. The process of packetizing data increases the total
amount of data to be transferred. Thus, larger packet sizes will reduce the
total amount of overhead for any given file to be transferred.
Additionally, ACK/NAK protocols will have to wait for
fewer ACKs and NAKs to be sent by the receiver if the packet size is larger.
YMODEM achieves speed advantages over XMODEM by using a larger packet size.
In some cases, however, you will actually be better off with smaller packet
sizes. For example, if a data packet is corrupted it must be retransmitted.
If many packets are being corrupted due to a bad phone line or improper flow
control, you will be better off using a smaller packet size. The BLAST protocol
allows the user to set the packet size in order to tune the protocol for
maximum performance. This is useful in situations where you may regularly
have a large number of corrupted packets when transmitting files to a particular
machine. You should set the packet size as small as possible when communicating
with that site. Packet size should be set as large as possible when transferring
files to machines that experience little data corruption.
For transmitting data over packet switched networks like X.25 and X.29 it
is important to tune packet size to the network configuration in order to
maximize performance and minimize overhead and cost of using the network.
A BLAST technical note is available to guide you in setting the tunable
parameters of the BLAST protocol for use over packet switched networks.
Q.
What does window size mean?
A. The number of packets a
sliding window protocol can transmit before
it must stop and wait for acknowledgments is known as the window size.
Adjustable window sizes makes a sliding window protocol more flexible. For
example, when other types of flow control are not available, it is sometimes
useful to make a sliding window protocol work like an ACK/NAK
protocol. This can be done with the the BLAST protocol
by setting the Window Size to 1 and ACK request
frequency to 1 in the BLAST protocol submenu.
Q.
What is ACK request frequency?
A. The BLAST
protocol packetizes ACK and NAK responses from the receiving system.
This guarantees the integrity of the response from the remote system at the
cost of a small amount of additional overhead resulting from the packetizing
process. Overhead can be reduced by putting many responses into one packet.
The number of responses per ACK packet is controlled by the ACK request frequency
in the BLAST protocol submenu. The ACK request frequency can be set from
1 to the window size.
Q.
What is flow control?
A. Both serial ports and modems
have data buffers. When data is received too quickly, these buffers get overrun
causing data corruption. Flow control paces the data stream to prevent the
loss of characters. It is crucial to have flow control properly set to maximize
file transfer and terminal scrolling speeds. There are two types of flow
control. One is Hardware, or RTS/CTS, flow control. The second is Software,
or XON/XOFF, flow control.
Q.
What is Hardware or RTS/CTS flow control?
A. Hardware or RTS/CTS flow
control uses the RS-232 Request-To-Send (RTS) and Clear-To-Send (CTS) signals
to pace the data stream. To successfully use RTS/CTS flow control, you must
have the following: a modem cable with full modem controls, a correctly
configured modem and some help from the operating system. In general, you
should never attempt to use RTS/CTS flow control with a hardwired connection
unless you have a special cable.
RTS/CTS flow control is very reliable, if your equipment and operating system
support it correctly. Most DOS/Windows machines do a good job of supporting
hardware flow control. Some Unix machines are capable of supporting it while
others are not. To work correctly, the serial port device driver must raise
the RTS signal when it is ready to receive data. The modem must only transmit
data to the serial port when the RTS signal is high. The modem must raise
the CTS signal when it is ready to transmit data to the remote modem. The
serial port device driver must only transmit data to the modem when the CTS
signal is high.
If you experience problems with RTS/CTS flow control on a Unix machine, it
is likely the serial port device drivers do not support bi-directional flow
control as described above. Some Unix device drivers are designed to raise
the RTS signal when the serial port is ready to transmit data. The device
driver then expects the modem to raise the CTS signal when it is ready to
receive the data from the computer. In other words, RTS/CTS flow control
is uni-directional. There is no provision for controlling the flow of data
from the modem to the computer. Some modems can be configured for this type
of RTS/CTS flow control. As long as the modems are not run at high speeds
it will probably work acceptably. However, we recommend you use XON/XOFF
flow control if your Unix machine does not support bi-directional RTS/CTS
pacing.
Q.
What is Software or XON/XOFF flow control?
A. Software or XON/XOFF flow
control is based on use of the ASCII DC1 (XON) and DC3 (XOFF) characters.
To start the flow of data an XON is inserted into the data stream. To stop
the flow of data an XOFF is inserted into the data stream. The process is
analogous to starting and stopping terminal scrolling by pressing the CTRL-S
(XOFF) and CTRL-Q (XON) keys.
XON/XOFF flow control is very widely used and is quite reliable. However,
there are some potential problems with it.
-
The file transfer protocol must not use the DC1 and DC3 characters to transmit
data. If the file transfer protocol does not filter out DC1 and DC3 characters
from the data, transmissions will hang because the modem will halt the flow
of data upon receipt of an XOFF character. XMODEM and YMODEM can not be used
with XON/XOFF flow control for this reason.
-
Starting and stopping of data does not happen in real time. XON/XOFF characters
are inserted into the data stream and there may be a substantial delay between
when they are issued and when they are received by the other device. This
can cause data loss if the buffers are overrun in the meantime.
-
If the XON character is lost in transmission, the file transfer protocol
must implement a procedure to restart transmission after some reasonable
delay or the transfer will be irrevocably halted. The BLAST protocol, for
example, will reset the device driver to begin transmitting data if it does
not receive an XON within 30 seconds of receiving an XOFF character.
-
In complex communications environments, it is possible to have many different
pieces of equipment attempting to control data flow. For example, the device
driver for the serial port, modems, terminal server, and X.25 PADs can all
be configured to assert flow control.
XON/XOFF flow control works successfully in one of two ways. In a simple
environment a local flow control loop works best. In a more complex environment
an end-to-end flow control loop is most likely to work. A local flow control
loop is established when each modem is configured to act on the XON/XOFF
characters sent by the attached computer. In this environment, the serial
port device driver will issue an XOFF when its data buffers are full. In
response to the XOFF character, the modem will halt the flow of data to the
computer. The modem will resume transmission when it receives an XON from
the computer. Likewise, the modem will issue an XOFF to the serial port when
its buffers are full.
The modems must be configured to act on the flow control characters but not
allow them to pass to the remote machine. No other devices should be configured
to assert flow control. For best results, the modems should have an
error-detecting connection established. With this type of connection, the
modems will control the flow of data between themselves. BLAST does not recommend
using a local flow control loop unless an error-detecting connection exists
between the modems. By default this is the type of flow control loop BLAST
establishes when XON/XOFF pacing is enabled.
In a more complex environment, or if error-detecting modems are not available,
end-to-end XON/XOFF flow control should be used. In an end-to-end environment,
the device driver will issue an XOFF when the serial port's data buffers
are full. The XOFF character will pass through all devices to the remote
computer, which will stop data transmission. When the buffers are empty,
an XON will be issued to cause the remote machine to restart the flow of
data. In similar fashion, if the remote machines's serial port data buffers
fill up, it will issue an XOFF that causes the local machine to halt data
transmission until an XON is received.
In this environment, all flow control should be disabled in the modems and
all other equipment. You must manually configure the modems to do this or
write your own script in modems.scr.
Q.
I am using a PC with DOS and I have configured my modem for COM3. How
do I initialize BLAST to work on these ports?
A. An important fact to keep
in mind when setting up your modem is that names like COM1: and COM2: are
just names for a CPU interrupt request number (IRQ) and a hardware base address.
Fortunately, most of the world agrees that COM1: represents IRQ 4 and base
address 3F8. COM2: represents IRQ 3 and base address 2F8.
There is no such agreement about what any other COM port represents. So,
your correct IRQ and Base Address must be obtained by studying the documentation
for your hardware. Diagnostics such as MSD or serial port settings in the
control panel may also be useful.
To tell BLAST where to find the IRQ and Base Address for a serial port, edit
the BLAST.OPT file in the directory where blast.exe is located. You can use
any ASCII text editor like edit.exe or notepad.exe to edit the file. You
may have to create a BLAST.OPT file if one does not already exist in the
BLAST directory.
The format of the COMMPORT setting in BLAST.OPT is:
COMMPORT=Label, IRQ, Base Address
Where Label is the name of the port, IRQ is the interrupt request number
and Base Address is the hexadecimal hardware address of the serial port.
For BLAST to recognize a modem as COM3: at IRQ 5 and base address 3E8, place
the following line in your BLAST.OPT file:
COMMPORT=COM3:,5,3E8
In addition, check that no other device or software attempts to share the
IRQ used by your modem.
Below are some examples of BLAST.OPT settings for common COM3: and COM4:
COMMPORT=COM3:,4,3E8
COMMPORT=COM4:,3,2E8
You may notice that COM1: and COM3: apparently both use IRQ 4 and COM2: and
COM4: both use IRQ 3. This is not a misprint and may lead the unaware to
believe it is possible for two serial ports to share an interrupt. To guarantee
error-free transmission of data, BLAST is unable to share interrupts. So,
be certain your serial ports are configured to use unique IRQs.
Q. I am
using the DOS version of BLAST under Windows. What can I do to optimize BLAST's
performance in a DOS window?
A. When you install BLAST,
the installation program asks if you are going to use BLAST under Windows.
If you say yes, a line is added to your APPS.INF file. You may later create
a BLAST.PIF file that has appropriate settings for running BLAST under Windows.
Call BLAST Technical Support for further information on using BLAST under
Windows.
Q.
Is MacBLAST Professional backwards compatible?
A. MacBLAST Professional will
operate under Macintosh System 6 and 7. You can use scripts and setups created
previously with MacBLAST 8.4; however, new commands and variables are supported
in MacBLAST Professional and you may want to revise your scripts to take
advantage of these new features. MacBLAST Professional resolves problems
that MacBLAST 8.4 had under System 7.
Q.
Can I use previously created keyboard maps with MacBLAST Professional?
A. The current version of the
MacBLAST Utilities creates keyboard maps in a slightly different way in order
to take advantage of the new format for Softkeys. You should create new keyboard
maps for MacBLAST Professional using the current version of the MacBLAST
Utilities rather than putting old maps into MacBLAST Professional.
Q.
Does MacBLAST Professional still use keyboard shortcuts and Softkeys?
A. The keyboard shortcuts have
been improved; you should look closely at the menu for changes in, and additions
to, the shortcuts. Softkeys have also been made easier to use.
Q.
Is there a special installation procedure for MacBLAST Professional?
A. Simply drag the MacBLAST
folder from the original floppy diskette onto your hard drive. The first
time that you launch MacBLAST Professional you will need to enter the serial
number printed on the package and the diskette label. Be sure to keep the
original MacBLAST Professional diskette write-protected and stored in a safe
place. DO NOT run MacBLAST from the original diskette.
Q. Can
MacBLAST Professional remote control a DOS PC?
A. No. MacBLAST has no remote
control capabilities.
Q.
How does BLAST use device drivers on Unix systems?
A. Under Unix, BLAST does not
manipulate the communications hardware directly. Instead, BLAST communicates
with either a device driver for a serial port or the telnet daemon for network
connections.
The serial port device driver negotiates all interaction with the hardware.
For example, if you specify hardware flow control in the BLAST setup, BLAST
attempts to set the device driver to use hardware flow control. BLAST has
no control how hardware flow control is actually implemented in the device
driver.
Q.
How does BLAST make network connections?
A. BLAST makes network connections
using your system's telnet program. Networking services must be correctly
configured on your system for BLAST to make a successful connection. Proper
configuration includes having the host name in /etc/hosts or using Domain
Name Services. Connecting to a specific port number requires the port number
be found in the /etc/services file. For more information on these configuration
files, consult the hosts and services manual pages. For example to connect
to a modem on port 3001 of a terminal server called ts01, the name ts01 must
be resolvable via either the hosts file or Domain Name Services while the
port is found in the services file. You can telnet to modem via BLAST by
entering:
ts01 3001
in the Connection field of the BLAST setup.
Q. How
are serial ports controlled on SVR3 Unix systems?
A. On older SVR3 Unix systems,
serial ports are handled by the system programs: init; getty; and login;
and the inittab configuration file. These system programs form a tight
init-getty-login-shell (IGLS) loop. In general, any attempt to control a
serial port outside the IGLS cycle breaks the system's control of the resource
and violates the Unix design philosophy. In other words, there is no provision
within SVR3 Unix system to handle anything other than terminals attached
either directly to a serial port or a terminal dialing into a modem attached
to a serial port! You can attach a modem to a serial port to use for dial
out purposes. However, if you want to use the same modem to dial out that
Unix wants to control via the IGLS cycle you are violating the design of
the Unix system. The implications of the IGLS design philosophy are profound
for users and software developers.
The init process, process number 0, runs all the time. Every so often it
reads the file /etc/inittab to see if there is anything to do. For example,
if there is a line in inittab like:
tty0:23:respawn:/etc/getty /dev/tty0
init will start a getty process on the serial port /dev/tty0 as long as the
current run level of the Unix system is either 2 or 3. The first field in
the above line, tty0 is just a user defined tag that init uses as an index
into the inittab file. It must be unique and hopefully will convey some
information to humans reading the inittab file.
The getty process is a simple-minded task. It reads /etc/gettydefs to find
out how to set the port for data bits, parity, flow control, etc. and then
waits patiently for some sign of life on the port. As soon as some sign of
life, like a carriage return, is seen, getty starts a login process and exits.
The login process does exactly what you expect. It prompts the user for a
valid login id and password combination. It then consults the /etc/gettydefs
file to see how the port should be set at login time. Then it spawns a shell
and exits.
The shell program (sh, ksh, csh, bash, etc.) is the command line interpreter
that all Unix users know and love. When the user finishes using the shell
by exiting or sending an EOT (^D) character, the shell exits.
The Unix kernel then notices the shell has died and knows the terminal on
which the shell was running is no longer in use. The kernel sends a message
to init telling it that the terminal has been released by the shell. init
reads /etc/inittab to find out what to do on the port and the process starts
over again.
Q.
How does BLAST control a serial port on an SVR3 Unix systems?
A. Within the IGLS scheme,
there is no provision for initiating an outbound connection. Even programs
like uucp (Unix-to-Unix-Copy) and cu (Call Unix) must either break the IGLS
cycle or use a serial port not controlled by the IGLS cycle to initiate an
outbound call. Taking a serial port outside the IGLS cycle and dedicating
it to outbound calling is the most reliable means of having in-bound and
out-bound lines. Unfortunately, this approach requires multiple modems and
phone lines to implement. Alternately, it is possible to share a port for
dial-in and dial-out processes. The IGLS cycle can be disabled on a port
by making a simple change in inittab:
tty0:23:off:/etc/getty /dev/tty0
Changing respawn to off tells init to shut down the getty process and not
to restart it.
Some Unix systems even provide a command to disable the getty. On SCO Unix,
for example the command:
disable tty0
will make the appropriate changes in the /etc/inittab file. To reenable the
getty you would type:
enable tty0
Your mileage may vary so check your system documentation and man pages.
As appealing as this approach may seem, there are some drawbacks. Allowing
users and applications to modify a system file like /etc/inittab poses a
threat to the integrity of the system. For a user or application to be able
to modify /etc/inittab requires write permission for the file which means
it can become corrupted. If the file becomes corrupted, your multi-user system
will slowly become a single and ultimately a no user system.
A number of mechanisms like uugetty and
lock files have been tried to solve this problem. None
of them have been wholly satisfactory or particularly reliable.
When BLAST accesses a serial port Unix system it does three things. First,
BLAST attempts to disable any getty running on the serial port by setting
the appropriate line to "off" in the /etc/inittab file. Next BLAST creates
a lock file in the appropriate directory or directories. When this is done
it attempts to set the serial port as specified in the setup file and open
it.
Q. What
is uugetty?
A. uugetty is a variant of
getty that tries to distinguish between in-bound and out-bound calls and
set the serial port appropriately. It is our experience that uugetty is difficult
to configure and not very reliable.
Q. What
are lock files?
A. A lock is a file placed
in a special directory that should prevent other applications from using
a serial port or other resource. The concept is that applications wishing
to use a serial port should check for the existence of a lock file prior
to opening the port. Unfortunately, there is no standard for where locks
should be written and what they should contain. Therefore, some applications
do not check for the existence of a lock while others misinterpret what locks
they do happen to find. For example, on SCO Unix, neither getty nor login
create a lock file when a user dials in on a port. The uucp program writes
a lock file in directory /usr/spool/uucp. Other applications write their
locks in /usr/spool/locks.
BLAST puts locks in the most common places for locks to be found on any given
Unix operating system. Common directories for locks are /usr/spool/uucp,
/usr/spool/locks/, /var/spool/locks, /var/spool/uucp and /etc/locks.
Q.
I am installing BLAST on my Intel-based Unix system and I only have a
5.25" drive. The diskette shipped to me is 3.5". What can I do?
A. Call BLAST for a 5.25" diskette
for installation.
Q.
Does BLAST have to be installed at both ends of the connection?
A. The answer to this question
depends on what you want to do. If you want to do:
Error-free file transfer with the BLAST Protocol - Yes
File Transfer using XMODEM, YMODEM, ZMODEM, or KERMIT - No
Terminal Emulation - No
Remote Control - Yes
Q.
What is "COPY PROTECTION ERROR"?
A. Receiving this error when
entering transfer mode with the BLAST Session protocol means that both copies
of BLAST have the same serial numbers. BLAST is serial-number protected;
each system must have a separate, licensed copy of BLAST with a unique serial
number.
In our Professional DOS and Professional Unix product we provide the user
with a separate BHOST diskette containing a copy of BHOST with a unique serial
number. This copy can be installed on a separate DOS-PC machine for two-way
communications.
Q.
How does data get corrupted during a file transfer?
A. In general, there are two
sources of data corruption during file transfers. One source is bad telephone
connections. The other is improper flow control.
Modern error-detecting modems practically eliminate bad telephone connections
as a source of data corruption. All of those MNP, V.whatever and LAP-M
designations on your modem means that data will be delivered error-free from
your modem. With a bad connection, the modems may have to do a lot of
re-transmission of data which will slow down throughput. Rest assured though,
that bad phone line are rarely a cause of data corruption as long as an
error-free connection is established by the modems.
If your modems are having to do a great deal of re-transmission of data you
may be able to achieve faster transfers by turning error-detection off. Some
modems attempt to retrain each time a they detect data corruption. With some
modems it can take several seconds to retrain. By turning error-detection
in the modems off, you can avoid the retraining process. The file transfer
protocol will accomplish the same error-detection without the re-training
down-time. To achieve the greatest throughput, use the smallest
packet size possible.
In our experience, improper flow control is the single greatest factor
contributing to data corruption. When you are making a high speed connection
it is imperative that flow control is correctly set. Otherwise, modem and
serial port buffers will be overrun and data will be corrupted.
Q.
What is Packet Switching?
A. A packet switched network
is a communications service offered by phone companies that transmits data
between computers in the form of packets. Packet switching is also known
by the X.25 and X.29 protocols used in the networks. Packet switching networks
are usually used to provide long distance networking capabilities to users
who do not have extensive enough needs to justify leased lines. Although
billing methods vary, packet switched networks usually charge for the number
of packets transmitted over the network instead of the amount of time connected
to the network. Thus, packet switching allows full-time connectivity to a
remote computer at a fraction of the cost of dial-up or leased lines charges.
For example, many banks use packet switching networks to connect terminals
in branch offices to their host machine in the home office.
Due to the packetizing process, packet switched networks introduce significant
delays into data transmission. In general, a packet switched network attempts
to fill packets before transmission. If a packet remains unfilled for too
long, the network will timeout and transmit the partially filled packet.
Since packet switched networks charge by the number of packet transmitted,
it is preferable to transmit full packets. However, waiting for too long
to transmit a packet will cause intolerable delays for interactive users.
The packetizing process will also slow down file transfers particularly if
you are using an ACK/NAK protocol. Performance of ACK/NAK
protocols suffer because they have to wait to send a packet until a response
is received from the remote system. The transmission of the ACK or NAK is
delayed until the packet switching network times out and sends the mostly
empty packet containing the ACK or NAK. To achieve maximum efficiency of
a packet switched network it is necessary to tune the packet size of the
file transfer protocol to the packet size of the network. If the packet sizes
do not match you will be sending partial packets which waste money And force
the network to time out prior to sending the packets. Most ACK/NAK protocols
used fixed packet sizes that may or may not match the packet sizes used by
the network. Sliding window protocols like BLAST with
tunable packet sizes are more well suited for use with packet switched networks.
File transfer performance does not suffer since the protocol is not forced
to wait for a response after packet is sent. Additionally, the protocol's
packet size can be tuned to match the network's
packet size to maximize efficiency. Furthermore, BLAST can
bundle multiple ACKs into one acknowledgement.
This reduces the number of network packets that must be transmitted to
acknowledge file transfer protocol packets. Check the BLAST Technical Note
on setting up the BLAST protocol over packet switched networks.
+44 (0) 1728 832 712
+44 (0) 1728 830 196
