>SOFTWARE @WW de:DK4NB 03.06.94 10:06 200 11487 Bytes
>DOC: the #BIN# protocol
>*** Bulletin-ID: 3154DB0AAB5F ***
>
>940531/2151z DB0JES, 940531/2127z DB0EAM, 940531/2121z DB0SIF
>940531/2109z DK0MTV, 940531/2106z DB0HOM, 940531/2106z DB0RBS
>940531/2101z DB0PIC, 940531/2100z DB0KCP, 940531/2100z DB0AAB
>From: DK4NB @ DB0AAB.#BAY.DEU.EU
>To : SOFTWARE @ WW
This is the documentation for the so-called #BIN# protocol, a
procedure for transferring binary and other data files without
undue overhead.
0) REVISION LOG
31 May 94 First published.
1) HISTORY
The original #BIN# protocol was probably devised by DL1BHO for use
with his TurboPacket program. The protocol underwent a number of
changes and improvements at the hands of ex-DL1MEN who is now DK4NB.
The #BIN# protocol is implemented in most packet terminal programs
utilizing the WA8DED host mode, such as TurboPacket, TOP, GP, SP and
others, as well as the F6FBB and TheBox BBS software.
As of today (June 1994), the most recent version of the #BIN#
protocol is only available in SP version 9. It is hoped that this
version is adopted by other packet terminal programs. Due to its very
low overhead, it is a natural for replacing the obsolete YAPP protocol.
2) PROTOCOL DESCRIPTION
2.1) BASIC
The basic #BIN# protocol consists of three elements:
The station transmitting the file (from now on called STATION A)
transmits
#BIN#nnnnn\r
and the station receiving the file (from now on called STATION B)
transmits
#OK#\r
in positive response, or
#NO#...\r
in negative response.
"nnnnn" = the length of the file in decimal bytes
"\r" = a RETURN character
"..." = any explanatory text as to why the file transfer is
rejected.
STATION B is to ignore any data not beginning with #OK# or #NO#.
All Elements are to start at the beginning of a frame and be contained
entirely within one frame. The frame immediately preceding an element
is to end with a return ("\r").
A transfer is aborted in midstream by one of the stations transmitting
\r#ABORT#\r
2.2) EXTENDED
The extended #BIN# protocol has last been changed in January 1994 and
is described as follows:
STATION A transmits:
#BIN#nnnnn#|ccccc#$dddddddd?#ssss\r
----- ----- -------- ----
! ! ! file name without path
! ! file date and time in 'struct ftime' format
! ! (BCC3.x) in hexadecimal notation (32 bits)
! The CRC of the whole file in decimal. Standard CCITT
! polynomial.
file length in decimal bytes.
The negative response by STATION B is defined as above. The positive
response
may be
#OK#\r (1)
or
#OK#ssss\r (2)
or
#OK#ssss#$nnnnn#ccccc\r (3)
---- ----- -----
! ! CRC of received file fragment
! number of bytes in received fragment
file name without path
Case (1) and case (2) are treated identically. Currently, the #OK#
file name is transmitted for information to the operator only,
since the receiving side is free to choose any file name.
Case (3) is the response used if it had previously been attempted to
transfer the file, and the transfer has failed due to a manual abort
or a broken link, or a disconnect. Note that when aborting, it is the
responsibility of the receiving station not to allow any extraneous
information, such as digipeater status messages or the #ABORT#
command or TNC status messages or any other data not belonging to the
received file to be stored. If the receiving station cannot guarantee
this, it should delete the file fragment.
When STATION A re-transmits the same file, STATION B should check for
existence of a previously stored file fragment. If there is a
fragment,then the data according to (3) should be determined and the
appropriate #OK# message should be transmitted.
The method of identifying a file fragment is up to the protocol
implementation. In the case of SP, the file extension contains a "$"
in place of the first character, e.g. "TEST.LZH" generates a fragment
called "TEST.$ZH". Better operating systems than MS-DOS allow long file
names which could be used to better denote a fragment.
STATION A, upon receiving the #OK# according to (1) or (2), should
commence transmission of the file. The logical conclusion of the file
transfer is achieved with the transmission of the last byte of the file.
Upon receiving #OK# according to (3), STATION A should determine the CRC
of the fragment and compare it with the CRC reported. Appropriate
measures must be taken if the CRCs do not match.
2.3) OPERATOR CHAT
While STATION A is in binary transfer mode (i.e. not all bytes of the
file have been committed to the TNC yet), the user is allowed to transmit
textual data not related to the binary transfer. All frames of such data
must be preceded by the string
SP\-
and STATION B must not regard frames starting with this string as
parts of the binary file transfer. This allows the operators to chat
while transferring the file. STATION B, when transmitting data, need
not take any precautions. STATION A must not cause an abort when receiving
any data from STATION B that does not consist of the special abort
element described above.
2.4) INABILITY TO RESUME
If STATION A is unable to resume an aborted binary transfer, it should
signal this to STATION B at the start of the transfer by not
transmitting the question mark ("?") shown in the #BIN# element above.
If this question mark is missing, STATION B is to take whatever measures
required to either reject the transfer or to quietly overwrite the fragment.
If STATION B is unable to resume an aborted binary transfer, it should
delete aborted file fragments or take whatever steps necessary to not
cause an error message should STATION A repeat the transfer attempt.
2.5) CRC ERRORS
If, at the end of a transfer, STATION B detects a CRC error, it should
report this to STATION A and take whatever steps required (e.g. delete
the damaged file). The format of this report may be of any kind, since
it is not used by the protocol.
2.6) SUCCESS
STATION B should, at the end of a successful transfer, transmit a
success message to STATION A. It is recommended that STATION A send one
to STATION B as well. Neither message will be part of the protocol
specification. Provisions should be made to transmit success messages
on a per CALL SIGN basis, so as to not send such messages to BBS systems,
which might be confused and report invalid commands. Success messages
only make sense when transmitted to a human operator.
3) AUTOMATIC #BIN#
Under certain circumstances, STATION B should react to the #BIN#
element even if it has not been placed in binary mode. An example would
be the reception of a binary file from a TheBox BBS, which simply sends
the ##BIN# element immediately followed by data. Normal procedure,
however, calls for some other means of initiation.
A second use for automatic #BIN# would be consecutive transmission of
multiple files. The list of files is to be controleld by STATION A,
and STATION B must be in a mode which allows automatic responses to
#BIN#. The protocol does not allow auto resume with automatic #BIN#.
4) INITIATION OF A BINARY TRANSFER
A binary transfer may be initiated at the programmer's discretion.
Usually, this will be a command issued by one of the two stations
involved. A typical constellation is a packet user controlling an
unattended station. That unattended station should place the
appropriate commands at the remote user's disposal. Implementation
of such remote commands depends on factors such as the programmer's
fancy or the general purpose of the station to be controlled and
their description is beyond the scope of this document.
5) FURTHER INFORMATION, CHANGE PROPOSALS
All communication regarding the Extended #BIN# Protocol is to be
directed to the author,
DK4NB @ DB0AAB.DEU.EU or Compuserve 100346,2236
(Internet [email protected]).
This specification is subject to change without prior notice. Any
changes will be published. Anyone making changes to this protocol
specification does so at their own risk.
6) CRC ROUTINE
The follwong C code consists of the standard CRC table and a macro
used to access the table.
/*
* crctab calculated by Mark G. Mendel, Network Systems
* Corporation
*/
unsigned short crctab[256] = {
0x0000,0x1021,0x2042,0x3063,0x4084,0x50a5,0x60c6,0x70e7,
0x8108,0x9129,0xa14a,0xb16b,0xc18c,0xd1ad,0xe1ce,0xf1ef,
0x1231,0x0210,0x3273,0x2252,0x52b5,0x4294,0x72f7,0x62d6,
0x9339,0x8318,0xb37b,0xa35a,0xd3bd,0xc39c,0xf3ff,0xe3de,
0x2462,0x3443,0x0420,0x1401,0x64e6,0x74c7,0x44a4,0x5485,
0xa56a,0xb54b,0x8528,0x9509,0xe5ee,0xf5cf,0xc5ac,0xd58d,
0x3653,0x2672,0x1611,0x0630,0x76d7,0x66f6,0x5695,0x46b4,
0xb75b,0xa77a,0x9719,0x8738,0xf7df,0xe7fe,0xd79d,0xc7bc,
0x48c4,0x58e5,0x6886,0x78a7,0x0840,0x1861,0x2802,0x3823,
0xc9cc,0xd9ed,0xe98e,0xf9af,0x8948,0x9969,0xa90a,0xb92b,
0x5af5,0x4ad4,0x7ab7,0x6a96,0x1a71,0x0a50,0x3a33,0x2a12,
0xdbfd,0xcbdc,0xfbbf,0xeb9e,0x9b79,0x8b58,0xbb3b,0xab1a,
0x6ca6,0x7c87,0x4ce4,0x5cc5,0x2c22,0x3c03,0x0c60,0x1c41,
0xedae,0xfd8f,0xcdec,0xddcd,0xad2a,0xbd0b,0x8d68,0x9d49,
0x7e97,0x6eb6,0x5ed5,0x4ef4,0x3e13,0x2e32,0x1e51,0x0e70,
0xff9f,0xefbe,0xdfdd,0xcffc,0xbf1b,0xaf3a,0x9f59,0x8f78,
0x9188,0x81a9,0xb1ca,0xa1eb,0xd10c,0xc12d,0xf14e,0xe16f,
0x1080,0x00a1,0x30c2,0x20e3,0x5004,0x4025,0x7046,0x6067,
0x83b9,0x9398,0xa3fb,0xb3da,0xc33d,0xd31c,0xe37f,0xf35e,
0x02b1,0x1290,0x22f3,0x32d2,0x4235,0x5214,0x6277,0x7256,
0xb5ea,0xa5cb,0x95a8,0x8589,0xf56e,0xe54f,0xd52c,0xc50d,
0x34e2,0x24c3,0x14a0,0x0481,0x7466,0x6447,0x5424,0x4405,
0xa7db,0xb7fa,0x8799,0x97b8,0xe75f,0xf77e,0xc71d,0xd73c,
0x26d3,0x36f2,0x0691,0x16b0,0x6657,0x7676,0x4615,0x5634,
0xd94c,0xc96d,0xf90e,0xe92f,0x99c8,0x89e9,0xb98a,0xa9ab,
0x5844,0x4865,0x7806,0x6827,0x18c0,0x08e1,0x3882,0x28a3,
0xcb7d,0xdb5c,0xeb3f,0xfb1e,0x8bf9,0x9bd8,0xabbb,0xbb9a,
0x4a75,0x5a54,0x6a37,0x7a16,0x0af1,0x1ad0,0x2ab3,0x3a92,
0xfd2e,0xed0f,0xdd6c,0xcd4d,0xbdaa,0xad8b,0x9de8,0x8dc9,
0x7c26,0x6c07,0x5c64,0x4c45,0x3ca2,0x2c83,0x1ce0,0x0cc1,
0xef1f,0xff3e,0xcf5d,0xdf7c,0xaf9b,0xbfba,0x8fd9,0x9ff8,
0x6e17,0x7e36,0x4e55,0x5e74,0x2e93,0x3eb2,0x0ed1,0x1ef0
};
/*
* updcrc macro derived from article Copyright (C) 1986 Stephen
* Satchell.
* NOTE: First argument must be in range 0 to 255.
* Second argument is referenced twice.
*
* Programmers may incorporate any or all code into their programs,
* giving proper credit within the source. Publication of the
* source routines is permitted so long as proper credit is given
* to Stephen Satchell, Satchell Evaluations and Chuck Forsberg,
* Omen Technology.
*/
#define updcrc(cp,crc) (crctab[((crc >> 8) & 255)] ^ (crc << 8) ^ cp)
-- END OF DOCUMENT ---
Sigi DK4NB @ DB0AAB.DEU.EU
Muenchen
Pr4Win by Bernd M. Stroj (OE8DJK), last updated on May 7, 1998.
