OS/2 Shareware BBS: 2 BBS

home *** CD-ROM | disk | FTP | other *** search

/ OS/2 Shareware BBS: 2 BBS / 02-BBS.zip / FSC.ZIP / FSC-0019.TXT < prev next >

Wrap

Text File | 1987-08-27 | 14KB | 363 lines

FSC-0019 SEALINK File Transfer Protocol August 24, 1987 Copyright 1986,87 by System Enhancement Associates, Inc. This document describes briefly the SEAlink file transfer protocol developers' package. SEAlink is a sliding window protocol that is fully backwards compatible with XMODEM in all tested implementations. The intent of SEAlink is to provide a file transfer protocol that does not suffer from propagation delays, such as are introduced by satellite relays or packet switched networks, while retaining full compatibility with XMODEM. Unlike other high-speed protocols, SEAlink does not "side step" to avoid using XMODEM, but instead works with an XMODEM driver to establish the fastest possible link, thus reducing startup delays in both SEAlink and XMODEM transfers. Actual tests of the enclosed routines has shown that SEAlink is capable of virtually eliminating propagation delays and turnaround delays. File transfers between New Jersey and Hawaii, which normally suffer a degradation of 50% or more due to satellite relays, proceed as fast as local transfers. Even transfers within the local exchange are speeded up by up to 20% at 2400 baud by the elimination of turnaround delays. Large volume tests show that SEAlink is capable of coming to within 2% of the theoretical minimum time for data transfer. The developers' package contains the following files: SEALINK.DOC This document. SEALINK.C A set of C routines for implementing SEAlink. CLINK.EXE A sample TTY program that implements SEAlink. You are granted a license to use this code in your programs, and to adapt it to your particular situation and needs, subject only to the following conditions: 1) You must refer to it as the SEAlink protocol, and you must give credit to System Enhancement Associates. 2) If you modify it in such a way that your version cannot converse with the original code as supplied by us, then you should refer to it as "SEAlink derived", or as a "variation of SEAlink", or words to that effect. In short, we're not asking for any money, but we'd like to get some credit for our work. This document is not meant to be a rigorous definition of the protocol. The code provided should serve to document the details and fine points of implementing SEAlink. We will, however, present a brief synopsis of how SEAlink adds sliding windows to XMODEM, and why XMODEM doesn't mind. First of all, SEAlink adds a block number to the ACK and NAK used in XMODEM.(1) We thus create "ACK/NAK packets", with the following structure: Byte 0: ACK, NAK, or C Byte 1: Block number Byte 2: One's compliment of block number This is identical in form to the first three bytes of a data packet, except that the SOH has been replaced with an ACK or NAK.(2) From the receiver's point of view, it does not matter if the trans- mitter is using sliding window or not. The receiver simply sends ACK and NAK packets as appropriate. Any XMODEM driver tested to date will simply ignore this excess data behind the ACK or NAK. From the transmitter's point of view, it just barely matters if the receiver can handle sliding window. The transmitter always acts as if it is sending sliding window, but varies the window size. If it is seeing valid block numbers and check values behind the received ACKs and NAKs, it sets the window size to six blocks. Otherwise, it sets the window size to one block. The result is that it only "sends ahead" if the receiver can handle it. It should be a fairly simple matter to apply the underlying SEAlink logic to almost any variant of XMODEM. The SEAlink routines provided in this package are also capable of passing system dependent information, such as true file size and time of last modification. This data is passed in a special header block. The header block looks exactly like any other block, except that it is block number zero. This is still backwards compatible with XMODEM, as a SEAlink receiver does not mind if block zero is missing, and any XMODEM receiver yet tested will regard block zero as a duplicate block and ACK it. (1) XMODEM/CRC uses a "C" in place of a NAK to indicate CRC error detection. SEAlink follows this convention, and supports either checksum or CRC. For brevity, this document will use the term NAK to mean either a true NAK (hex 15) or a C (hex 43). (2) See previous footnote. The data portion of block zero contains the following fields: Offset Size Contents ====== ==== ======== 0 4 Original file length. 4 4 Date and time file was last mofified, in seconds since 1979. 8 17 Original file name, as a null terminated string. 25 15 Name of transmitting program, as a null terminated string. 40 1 Overdrive flag. 41 87 Null filler and expansion area. Any field which the transmitter cannot support should be set to all zeros. Conversly, the receiver should ignore any null fields. The receiver may ignore any field which he cannot support. Of special interest is the byte flag at offset 40 in block zero. This is the "Overdrive flag", and is used to trigger streaming mode for high-speed, half duplex modems. In Overdrive mode the receiver stops sending ACKs for the bulk of the file transfer, thus facilitating transfers over a half-duplex connection. Overdrive is never required over a full duplex connection. Overdrive requires that the basic link be effectively error free. Overdrive is disengaged in either of the following conditions: o The transmitter will disengaged overdrive if it detects that the receiver has dropped out of overdrive, or does not support overdrive. o The receiver will disengage overdrive if it finds itself receiving an excessive number of bad blocks, as Overdrive requires an error-free link. The routines enclosed in this package should be reasonably easy to implement in your application. We have attempted to exclude compiler dependent and system dependent logic from these routines. You will need to alter our references to our communications driver to conform to your own driver. The communications related routines we use are: com_putc(c) Output character c to comm port. int com_getc(t) Get character from comm port within t tenths of a second. Return EOF if time limit expires. com_dump() Discard any pending output without sending it. In addition, we use the following routines for controlling timed loops: long timerset(t) Set a timer. Returns a timer value which will expire in t tenths of a second. int timeup(z) Check a timer. Returns true if timer z has expired yet, or false otherwise. These routines also make reference to the following functions for system dependent information, which is optional: filestat(name,&fs) Read directory entry for a file and return system dependent information. setstamp(f,dtg) Set a file's date/time of last modification. The SEAlink implementation provided in this package is used by invoking the two primary routines: int xmtfile(name) /* transmit a file */ char *name; /* name of file to transmit */ This routine is used to send a file. One file is sent at a time. If the name is blank (name is null or *name points to a null), then an end of transmission marker is sent. This routine returns a one if the file is successfully transmitted, or a zero if a fatal error occurs. char *rcvfile(name) /* receive a file */ char *name; /* name of file (optional) */ This routine is used to receive a file. One file is received. If a name is specified for the file, then that name WILL be used, and any name sent by the transmitter will be ignored. If the name is blank (name is null or *name points to a null), then the transmitter must provide a name for the file. This routine returns a pointer to the name of the file that was received. If the file transfer is not successful, then a null pointer is returned. The pointer returned by rcvfile() points to a static data buffer. This does not have to be freed (and should not be), but it will be overwritten the next time rcvfile() is called. The rcvfile() function works on a temporary file whose name is the same as the final file, but with a dash ("-") added at the beginning. If a file transfer is aborted, then this temporary file will be retained. An aborted file transfer will not harm a pre-existing file of the same name. In addition, this set of routines includes two global variables that may be set to affect the SEAlink driver. These are: int ackless; This is used to control the overdrive. It should be set to a non-zero value before calling the SEAlink transmitter if overdrive is desired. We recommend using overdrive at link rates greater than 2400 bps, and not otherwise. char *progname; This is used to set the "name of transmitting program" field in block zero. It should be set to point to a string constant. The SEAlink routines can be used for either single or multiple file transfers. To send multiple files, send each file one by one until either a transmit fails or all files are sent. If all files are sent, then signal the end by calling xmtfile() with a null pointer. To receive multiple files, call rcvfile() repeatedly until it returns a null pointer. This package includes a demonstration program named CLINK (pronounced "clink"), which is a simple TTY program for doing SEAlink file transfers. CLINK does not perform any sort of terminal emulation whatsoever. However, she will make use of the ANSI.SYS screen driver if you have it installed. CLINK may be used in either of two ways: interactive mode or command mode. To use CLINK in the interactive mode, give the command "CLINK" with no arguments. Press the "ESCape" key to give a command to CLINK. The command "?" (question mark) instructs CLINK to tell you what commands she understands. To use CLINK in the command mode, give the command "CLINK" with an argument. There are three arguments you can give CLINK in the command mode. These are: 1) Receive files; Do this with a command of the form: CLINK R CLINK will attempt to receive one or more files from COM1, and will terminate as soon as all files are received, or when the transfer aborts. 2) Transmit files; Do this with a command of the form: CLINK T <filename> ... CLINK will attempt to transmit the listed files over COM1, and will terminate as soon as all files are sent, or the transfer is aborted. <filename> may be one or more file names with or without drive and path specifiers. Wildcards may be used. 3) Give help; If you type: CLINK ? or any invalid command, CLINK will display a brief reminder of what arguments she understands in command mode. When CLINK is invoked in the command mode it normally uses COM1, does not alter the baud rate, and does not transmit in Overdrive mode. This can be altered by using any or all of the following command line switches: /P1 to use COM1: (default) /P2 to use COM2: /B<baud> to set baud rate /O for Overdrive CLINK comes with her own serial driver built in for the IBM PC family and true compatibles, but she is capable of using any standard FOSSIL driver.