The BLAST Session protocol defines a set of rules for file transfer and file management with a remote computer. Under the BLAST Session protocol, the following tasks can be performed:

• Files can be transferred between local and remote systems. The BLAST Session protocol permits files to be transferred bi-directionally--data is sent and received at the same time, with automatic error checking and data compression.

• Files can be manipulated on the remote computer. For example, files can be deleted, renamed, or printed on the remote. Because these tasks are mediated by the BLAST Session protocol, the commands cannot be garbled by line noise. In addition, the commands are automatically translated into the appropriate instructions on the remote computer--when you give the "List Files" command using the BLAST Session protocol, you will receive a directory listing whether the remote machine is a Macintosh, a VAX, or a computer running the UNIX operating system. You do not need to know the machine-specific instruction.

The BLAST Session protocol is much more sophisticated than public domain file transfer protocols. No public domain protocol has all the characteristics of BLAST session protocol. BLAST is generally faster than public domain file transfer protocols because it offers all of the following features:

• Bi-directional transfers.
  
• Six levels of compression.
  
• Sliding-window design.
  
• Automatic translation of text files between the local file format and the format of the remote system.
  
• Resumption of interrupted file transfer from the point of interruption.

BLAST Protocol Design

Bi-Directional and Sliding-Window Capability

The BLAST protocol is capable of transmitting and receiving data packets simultaneously. This simultaneous bi-directional transfer saves time and online charges when files need to be both sent and received.

BLAST operates efficiently over circuits with high propagation delays (the length of time from when a character is transmitted to the time it is received). This resistance to delays is due to BLAST’s sliding-window design.

The size of a window is the number of packets that can be sent to the remote computer without BLAST’s having to wait for an acknowledgement from the remote. As the remote computer sends acknowledgements, the window slides so that more packets can be sent. For example, if the window size is set to 16, and the first 4 of 12 packets sent have been acknowledged, the window slides to allow 8 more packets to be sent. In this way, a continuous stream of packets can be sent without BLAST’s having to wait for an acknowledgement. The window size and frequency at which acknowledgements are requested can be specified by the user.

These two features—simultaneous bi-directional transfer and sliding-window design—combine to make BLAST a great time saver for long-distance callers. For example, BLAST can upload daily production figures to a host computer over a noisy telephone line at the same time that it downloads the next day’s production quotas.

CRC Error Detection

BLAST protocol uses the industry-standard CCITT CRC-16 technique for detecting altered data packets. This is the same method used in IBM SNA/SDLC networks and X.25 packet-switching networks.

Optimized Acknowledgements

When packets of data are transmitted, they must be acknowledged by the receiving computer so that the sending computer knows that the transfer is complete and accurate. When data is being transmitted in only one direction, the BLAST protocol uses a minimal number of acknowledgement packets flowing in the other direction. When data is being transferred in both directions, the data and acknowledgment packets are combined into a single packet. This efficient use of packets is important when working with packet-switching networks because network charges are often computed on a per-packet rather than a per-byte basis.

BLAST Protocol Circuit Requirements

BLAST is flexible in its circuit requirements. BLAST encodes all data into "printable" characters; thus, it is compatible with the use of control characters for other purposes. For example, BLAST can be employed on circuits in which software flow control (XON/XOFF) is in use. Devices that normally honor XON/XOFF control cannot use Xmodem for binary file transfers because the flow control character, CTRL S, may be embedded in the data stream and will cause data transmission to halt when encountered.

BLAST will operate on 7-bit or 8-bit circuits. 7-bit operation allows BLAST to communicate with parity. This does not inhibit BLAST's ability to transmit binary data--you may transfer either 7- or 8-bit data over both 7- and 8-bit circuits. BLAST's ability to operate over both 7-bit and 8-bit connections allows file transfers over Telnet connections that are not guaranteed to be 8-bit clean.

When using BLAST to communicate with computers that require 7-bit circuits, the 7-Bit Channel parameter must be set to "YES," which will marginally decrease the throughput of the transfer.

Extensive File Transfer Session Logging

The BLAST Session protocol allows extensive logging of file transfer sessions. This enables creation of audit trails as well as automated file transfers.

Starting the BLAST Session Protocol

After you are online with the remote computer, the BLAST session protocol must be initiated on both the remote computer and the local computer.

Starting BLAST on a Remote Multi-User System

The BLAST session protocol can be started on the remote, multi-user computer "manually" or "automatically."

The Manual Method

To start the BLAST session protocol manually, send the command to the remote system to start the BLAST protocol. For example, to start BLAST in host mode running the BLAST protocol on a remote UNIX or VMS machine, issue the following script command:

tsend "blast -h", LF

This sends "blast -h," the command to start BLAST in host mode, to the remote system along with a line feed character to terminate the line.

To start BLAST in host mode on other machines, please consult the BLAST documentation for that machine.

The Automatic Method

To have Data Pump automatically start BLAST in host mode on the remote system, use the BLASTscript command FILETRANSFER. The FILETRANSFER command reads the System Type specified in the phonebook listing or the @SYSTYPE reserved variable and sends the appropriate commands to the remote system to start BLAST in host mode on the remote machine.

Starting BLAST on a Single-User Computer

If the remote computer is another single-user PC, you may start the BLAST Session protocol in one of several ways:

Attended Remote Method

Have the remote operator initiate a BLAST session on the remote system. After the session has started, you can control it from your keyboard; therefore, the remote operator is no longer necessary. In order for you to be able to end the session without remote assistance, however, the remote operator--before leaving--must execute the command to end the BLAST session on the remote system. Otherwise, the BLAST protocol will have to time-out to exit.

Unattended Method

Run a slave script on the remote computer to place the remote computer in "slave" mode, waiting for incoming calls.

BHost

Run BLAST BHost on the remote PC.

Starting BLAST in Data Pump

The BLAST session protocol is started on the local machine running Data Pump by issuing a FILETRANSFER command in your script. If you are running Blast.exe you will see the File Transfer Status dialog, which gives the status of the filetransfer activity.

Automatic BLAST Handshaking

While entering a BLAST session, the two computers will communicate for a few seconds on their own--they will "shake hands" by exchanging information. During handshaking, your PC will:

• Send its BLAST version type to be displayed and logged at the other end.
  
• Exchange BLAST transfer and communication parameters with the remote computer and adjust itself to the other machine's lowest setup values. For instance, if your settings specify a Packet Size of 256 bytes and the remote computer's settings specify 2048, then the lower value of 256 will be used.

This process can fail if it does not occur within the time period specified in the Logon Timeout field of the BLAST Protocol Settings dialog. If handshaking fails, BLAST displays "Session terminated."

BLAST Protocol Timeouts

There are two types of timeouts in BLAST protocol: the Inactivity Timeout and the Logon Timeout. Both timeout values can be specified in fields in BLAST Protocol Settings.

The Logon Timeout is the maximum time in seconds after initiating the BLAST Session protocol that BLAST will wait for the initial handshake with another system. The default value is "120." If a Logon Timeout is specified and BLAST waits longer than the maximum time specified to establish the BLAST session, it will discontinue the session.

The Inactivity Timeout is the maximum time in seconds allowed between the transmission of valid data packets. The default is 120 seconds. When BLAST times out, it will discontinue the session.

Either timeout can be disabled by setting it to "0"; however, setting the Logon Timeout to "0" at the remote site could lock up the remote. In this instance, Blast.exe allows you to "force" a disconnect by following these steps:

• Switch to the Terminal View by selecting the Terminal Viewer tab.
  
• When you see

           in the view, type:

                 ;DISC. ENTER

This message tells BLAST on the remote system to abort its attempt to enter a BLAST session. Because the message you type will not be echoed on the screen, repeat it several times if necessary. Note that the command is case-sensitive.

Ending the BLAST Session Protocol

BLAST sessions end automatically when all specified files are transferred and an ESC is encountered in the script.

If you are running Blast.exe, it is also possible to abort a BLAST protocol session by hitting the ABORT button on the File Transfer Status dialog.

BLAST Protocol Operations

After you have established a BLAST session with the remote computer, you can send and get files, execute remote commands, and send messages to the remote system. If you are running Blast.exe, you will see the File Transfer Status dialog. Terminal activity is disabled while the BLAST session is active.

Sending and Receiving Files with BLAST

Below is a script that illustrates sending and receiving files using the BLAST protocol. The script is getting a file called "Sales_data" in the subdirectory Daily\ on the remote machine. The file will be saved as "C:\Tmp\Sales_data." The "to" option at the end of the line directs Data Pump to transfer the file as text and to overwrite the file on the remote system if it exists.

The script is sending a file called "Price_changes" in the C:\Tmp\ directory to the subdirectory New_prices\ on the remote machine. There are no file transfer options specified on the line, so no special processing of the file will occur during the send.

The script also illustrates the use of a file transfer template. The script is sending a file called "inventory" in the C:\tmp\ directory to the remote machine. The "%" template instructs the BLAST protocol to strip off all path information and save the file in the current directory under the name "inventory."

FILETRANSFER GET "daily/sales_data", "C:\\tmp\\sales_data", "to" SEND "C:\\tmp\\price_changes", "new_prices/price_changes" SEND "C:\\Tmp\\Inventory", "%" ESC

If you are running Blast.exe, you will see the File Transfer Status dialog, which gives the status of the files being transferred.

Remote Commands

Data Pump supports the following remote commands during a BLAST session: RCHDIR, RDELETE, RLIST, RPRINT, RRENAME, and RTYPE. If you are running Blast.exe, any output will be in the message area of the File Transfer Status dialog. For compatibility with old versions of BLAST, the REMOTE command with the CHDIR, DELETE, RENAME and LIST directives are still supported. However, usage of the REMOTE command is deprecated.

Local Commands

The Data Pump supports the following local commands during an BLAST session: LCHDIR, LDELETE, LLIST, LPRINT, LRENAME, LRUN, LSYSTEM, and LTYPE. For compatibility with old versions of BLAST, the LOCAL command with the CHDIR, DELETE, RENAME, PRINT, SYSTEM, and LIST directives are still supported. However, usage of the LOCAL command is deprecated.

Specifying Transfer Options

Text

Text is specified by putting a "t" at the end of a SEND or GET command. Text specifies text translation from DOS file format to the destination system's text file format. This option should only be used with ASCII files you wish to translate to the text file format of the remote system--do not send binary files using the text option. For compatibility with older versions of BLAST, text translation can be specified by including either the /T=TXT or /TXT switch at the end of the filename. However, usage of the /T=TXT or /TXT switches are deprecated. BLAST assumes a binary file transfer if this option is not specified.

filetransfer send "C:\\daily\\daily.sal", "pittsboro/daily.sal", "t" esc

Overwrite

Overwrite is specified by putting an "o" at the end of a SEND or GET command. Overwrite causes the transmitted file to overwrite an existing file of the same name on the receiving system. Use of this option will result in the destruction of the existing file; thus, use Overwrite with caution. An error will result if this option is not used and the file already exists on the receiving system. For compatibility with older versions of BLAST, overwrite can also be specified by including the /OVW switch at the end of the filename. However, usage of the /OVW switch is deprecated.

filetransfer get "daily_data", "C:\\milwaukee\\data\\sales", "o" esc

Append

Append is specified by putting an "a" at the end of a SEND or GET command. Append appends the transmitted file to the end of an existing file with the same name on the receiving system. If the file does not exist on the receiving system, it will be created. For compatibility with older versions of BLAST, Append can also be specified by including the /APP switch at the end of the filename. However, usage of the /APP switch is deprecated.

filetransfer get "company-news", "news", "a" esc

Store

Store is specified by putting an "s" at the end of a SEND or GET command. Store deletes a file from the receiving system if the transfer was unsuccessful. For compatibility with older versions of BLAST, Store can be specified by including the /STR switch at the end of the filename. However, usage of the /STR switch is deprecated.

filetransfer send "C:\\weekly\\report", "D:\\moncure\\weekly.sal", "s" esc

Forward

Forward is specified by putting an "f" at the end of a SEND or GET command. Forward deletes a file from the sending system if the transfer was successful. The Forward option is a powerful feature of BLAST. Because use of Forward will automatically delete files from the sending system, always exercise caution when using Forward. For compatibility with older versions of BLAST, Forward can also be specified by including the /FWD switch at the end of the filename. However, use of the /FWD switch is deprecated.

filetransfer get "report", "C:\\bonsal\\report", "f" esc

Compression

File transfer compression level is specified by putting a "cn" at the end of the SEND or GET command, where "n" is the level of compression between 0 and 6. Data compression increases the efficiency of the file transfer if the file is compressible. If a file has already been compressed, you should set the compression level to "0." For compatibility with older versions of BLAST, compression can also be set by including the /COMP=N switch at the end of the filename, where "N" equals the level of compression (1 - 6). However, use of the /COMP=N switch is deprecated.

filetransfer get "C:\\reports\inventory.dat", "inventory.dat", "c4" esc

No Overwrite

No overwrite is specified by putting an "n" at the end of a SEND or GET command. No Overwrite causes the transmitted file not to overwrite an existing file of the same name on the receiving system. Because No Overwrite is the default, it is not actually needed. However, to be explicit, you may add it to a script.

filetransfer send "C:\\Retail\\daily.dat", "D:\\Retail\\daily.sal", "n" esc

Binary

Binary is specified by putting a "b" at the end of a SEND or GET command. Binary specifies file transfers in binary mode. Because Binary is the default, it is not needed. However, to be explicit, you may add it to a script.

filetransfer send "C:\\Midwest\\report", "D:\\Midwest\\weekly.sal", "b" esc

Transfer Option	BLAST		FTP		Xmodem
	GET	SEND	GET	SEND	GET	SEND
T (Text)	X	X	X	X
O (Overwrite)	X	X	X		X
A (Append)	X	X	X		X
S (Store)	X	X
F (Forward)	X	X
CN (Compression, level)	X	X
N (No Overwrite)	X	X	X		X
B (Binary)	X	X	X	X

Special Considerations

To take full advantage of the BLAST Session protocol, keep the following points in mind:

• BLAST attempts to queue as many remote commands as possible (like GETs) before issuing local commands (like SENDs). This behavior permits BLAST to transmit files in both directions simultaneously, but it also means that files may not be transmitted in the order specified in the script.
  
  
• Many filetransfer and file management commands can be combined into one FILETRANSFER-ESC block, as in the following example:

  filetransfer                # begin Filetransfer mode   send "*.txt", "%', "ta"     # send file; use template, text transl, & overwrite   rchdir "/usr/customer"      # change remote directory   rprint "client.log"         # print remote file   esc                         # exit Filetransfer mode

  Combining operations allows BLAST to work more efficiently, saving online charges or other long-distance telephone costs.
  
  
• Errors that occur during file transfer can be checked by testing the value of @EFERROR or by examining an @EFLOG file after exiting Filetransfer mode. If extended logging is enabled, additional reserved variables give information about the number of successful transfers and the number of failures.
  
  If the line is dropped during a file transfer, BLAST can either ignore the problem or abort Filetransfer mode immediately. The action BLAST takes is determined by the setting of the DCD Loss Response field in the phonebook listing. Your choice for DCD Loss Response setting ("ABORT" or "IGNORE") may depend on your environment. For instance, you might need to ignore carrier loss if the carrier drops intermittently due to line noise and your modems are configured to retrain automatically.

If a BLAST transfer session is interrupted and you wish to restart from the point of interruption, both local and remote systems must have timed out or have been interrupted by an Abort. After the session has been interrupted or aborted, you may restart the session by following these steps:

• Reconnect, if necessary, and restart BLAST transfer.
  
• Send the exact file that was being sent when interrupted.
  
• Do not indicate the overwrite or append options.

BLAST restarts from the last point at which its buffers were flushed to disk. This may be right at the interrupt point or as much as 10K before the interrupt point.

BLAST Transfer Security

Disabling File Overwrites and Remote Commands

Disabling the Allow OVW and Remote Commands option in the BLAST Protocol Settings disallows the remote computer from overwriting files on your local system and from performing remote commands except for RLIST and RTYPE. You will still be able to send a file with the Overwrite transfer option, described above.

Disabling the Forward and Store Transfer Options

Disabling Forward and Store options in the BLAST Protocol Settings will prevent the deletion of any partially or wholly transferred files on your local computer. You will still be able to get a file from the remote computer with the "f" transfer option because the file deletion will take place on the remote computer if the transfer is successful. See the descriptions of Store ("s") and Forward ("f") in Specifying Transfer Options above.

Using the Transfer Password

When you specify a Transfer Password on your computer, it will restrict access by a remote user during a BLAST session. If the remote user does not provide the password, the only functions available to the remote user are sending and receiving messages. To specify a transfer password, enter a password in the Transfer Password field of the BLAST Protocol Settings or set the @TRPASSWD reserved variable in a script (for instance, in a slave script).

After entering BLAST transfer, the remote computer must send the transfer password to the local system; this is done with the BLASTscript RPASSWORD command:

RPASSWORD "password"

For example, if the password on the local computer were "xm24ty" and the remote computer wanted to send the file "C:/usr/sales.dat," the remote computer would have to issue the following FILETRANSFER command block.

filetransfer   RPASSWORD "xm24ty"   send "sales.dat", "sales.dat" esc

If the transfer password is changed on the local computer, the remote computer must send the updated password via a FILETRANSFER statement.

NOTE:  Transfer Password is intended to validate remote users logging onto your system. If Data Pump running on your system loads a phonebook listing with something typed in the Transfer Password field, you will not be able to receive files without the remote computer sending the password.