Amateur Multicast Protocol (AMP-2)

Version 2.0.0 - W1HKJ <w1hkj@w1hkj.com>

Derived from Amp 1.0, by Walt Fair, Jr., W5ALT

revised 10/05/12, 0630

Disclaimer

This is an unofficial extension of the original Amp specification which is maintained by the Society for the Preservation of Amateur Radio.

General description

Multicasting is  a non-connected protocol and the receiving stations are totally passive, there is no need for hand shaking and related overhead. The server simply repeatedly sends files, with enough information to allow them to be identified, checked for errors and stored. The clients or receiving stations, likewise, have no need to transmit, but simply listen for any files of interest, receive and saves them and checks for errors. If errors are found, the receiver simply waits until the file is sent again and attempts to retrieve the portion that was bad.

No distinction is made between text and binary files.  Either may be compressed, encoded using base numeric system encoding, or transmitted in original form.  Information regarding compression, encoding or other file manipulation is contained within the data transmission and is not an inherent part of the protocol.

In order to transmit files for remote reception, the minimum information needed is the name of the file and it's modification date-time, the method used for uncompressing the file (if compressed), the base encoding system (if used, ie: base-64 ...) and the data contained in the file.  The combination of modification date-time and file name is sufficient to make each file transfer uniquely identifiable.  Cycle Redundancy Checksum (CRC-16) values for each element of the protocol is used to ensure accuracy of reception. For subsequently storing missing data blocks, a block number is also necessary to indicate the data block sequence.

Any amateur radio transmission mode which supports the full ANSI character set may be used as the transport layer.

Since the transmission is to be done using commonly available systems, it is useful to further identify the information. Of course, as in all amateur communications, there is also the legal necessity of station identification, too.

Protocol elements

The Amateur Multicast Protocol (AMP) version 2.0 consists of a sequence of elements described as follows.

Each protocol element consists of a keyword with character count and checksum enclosed in angle brackets (< >), followed by an optional block number and the specified data. Other information within the brackets may be included, but will be ignored by the receiving station. The optional text information may be useful for comments and other purposes.

For readability, a carriage return (or anything else) may be sent following the data and it should be ignored by the receiver.

The overall format of a protocol block is:

<keyword [Byte-count Checksum]>[{HASH:Block-number}][data]


keyword uniqely identifies the use of each Amp block

Byte-count. The byte count contains the number of bytes in the data block. For file names, descriptions, etc. it is the number of characters comprising the name or character string. For file content blocks, it represents the number of bytes transmitted in the data block, irregardless of how they might be handled by the client (receiver) software.


Checksum. The checksum is used by the receiving station to determine the accuracy of the received data. It is a 16 bit cycle redundancy check (Crc16) value.  Crc16 C++ code is found in source file crc16.h associated with the application flamp. The CS value is always transmitted as a 4 character hex string.

HASH is a 4 character hexadecimal number that is the Crc16 value associated with a concatenated string which consists of the date-time, colon, and the filename, ie:

20120915002015:testfile.txt.

where the date-time is the the sytstem date-time stamp associated with the file's last modificiation.

Block-number. The block number is only needed while sending file contents. For transmission, the file is divided into convenient sized blocks (64 bytes is recommended) and each block is numbered starting with 1 for the first block sent, 2 for the second, etc. The use of a block number allows the client software to keep track of what part of the file has been correctly received and which parts are still incorrect, so that the needed blocks can be received during a subsequent transmission.

Protocol blocks

<PROG # CS>[name and version of software used to generate the Amp text stream].

<ID # CS>callsign other info. Every transmission should begin with the station identification. In addition, at regular intervals (at least every 10 minutes and at the end of a communication in the US), there is the legal requirement for station identification. In order to separate the identification function from other data, the ID keyword should be used.

In many cases the receiver is free to ignore this keyword, unless needed for logging or other purposes. The main reason for including station identification as a separate keyword block is in order to separate identification data from file data in the middle of file transmission and reception.

Example: <ID 15 C2BC>W1HKJ Toney, AL

<FILE # CS>date-time:file-name, the modification date-time and name of the file to be transmitted is sent as data following this keyword.

Example: <FILE 29 2499>20120915022802:jabberwock.txt

<SIZE # CS>{HASH}FSIZE NBLOCKS BLKSIZE.  The size of the file, in bytes, the number of data blocks to be transmitted and the block size is sent as data following this keyword in normal ASCII decimal. The following example represents a file that is 200 bytes long and will be sent in 4 data blocks. Note that the 8 for character count indicates the length of the data, which is "332 6 64".

The data blocks will be 64, 64, 64 and 8 bytes long.

Example: <SIZE 15 F244>{2499}586 10 64

<DESC # CS>textual description. An ASCII description of the file to be transmitted is sent as data following this keyword. This is an optional field.

<DATA # CS>{HASH:BlkNum}. The actual data contents of the file to be transmitted is sent as data following this keyword. File contents are usually sent in consecutive DATA blocks, each with a block number starting with 1, a character count (i.e. block size) and check sum. This a change from the original Amp protocol. The Block Number must be a part of the data line so that it is included in the Crc-16 checksum.  Data transmissions may also consist of a partial list of DATA blocks. 

Example1:

<DATA 72 240C>{2499:1}[b256:start]526

=LZMA:0:0:3-]:0:0:0:4:0=l=--(-t;=-h-zw-------a)-

Example2:

<DATA 72 A5E6>{2499:2})F---===-----,R-:3--=--k/:AMA--{-7-=---\9---\-:C-cO--)<-B:4--:Ad

(Example 1 contains an embedded line feed character)

(Example 2 contains compressed, base256 encoded data; unprintable characters represented by '-' and '=')

<CNTL # CS>control-word. This keyword indicates that a transmission control word is the data load.  The control word may be either EOF (end of file) or EOT (end of transmission).

Examples:

<CNTL 5 9016>{EOF}

<CNTL 5 301A>{EOT}

Multiple file transfers

Several files may be transfered within a single Amp transmission.  The protocol insures that each file and it's data blocks are uniquely identifiable so that an error free recreation of the file is possible at the transfer destination.

Transfer Examples:

Original text:

paris paris paris paris paris paris paris paris paris paris
PARIS PARIS PARIS PARIS PARIS PARIS PARIS PARIS PARIS PARIS
paris paris paris paris paris paris paris paris paris paris
PARIS PARIS PARIS PARIS PARIS PARIS PARIS PARIS PARIS PARIS

Text data transfer:

<PROG 13 0146>FLAMP 1.0.0AM
<FILE 24 583A>20121005120009:paris.txt
<ID 20 D575>W1HKJ Toney, Alabama
<SIZE 14 A148>{583A}240 8 32
<DATA 40 118B>{583A:1}paris paris paris paris paris pa
<DATA 40 D54E>{583A:2}ris paris paris paris paris
PARI
<DATA 40 ADFF>{583A:3}S PARIS PARIS PARIS PARIS PARIS
<DATA 40 D3CA>{583A:4}PARIS PARIS PARIS PARIS
paris pa
<DATA 40 0244>{583A:5}ris paris paris paris paris pari
<DATA 40 0BB3>{583A:6}s paris paris paris
PARIS PARIS
<DATA 40 609B>{583A:7}PARIS PARIS PARIS PARIS PARIS PA
<DATA 24 B689>{583A:8}RIS PARIS PARIS

<CNTL 5 9016>{EOF}
<CNTL 5 301A>{EOT}

Compressed text data transfer:

The above file was compressed using the LZMA algorithm and then base encode using base-64 encoding.  Base-64 insures that all characters in the transmission will be contained within the supported character set of most available amateur radio transport layers (digital modem types).

<PROG 13 0146>FLAMP 1.0.0AM
<FILE 24 583A>20121005120009:paris.txt
<ID 20 D575>W1HKJ Toney, Alabama
<SIZE 13 8A6D>{583A}77 3 32
<DATA 40 DE3B>{583A:1}[b64:start]AUxaTUEAAADwXQAAAAQAO
<DATA 40 CAAB>{583A:2}BhKq0E6M4uCxrH2FRC3VLLDLOKtP7V2A
<DATA 21 EE0F>{583A:3}AA=
[b64:end]
<CNTL 5 9016>{EOF}
<CNTL 5 301A>{EOT}

The same file compressed and then base-256 encoded (unprintable characters are shown as '-' or '=')

<PROG 13 0146>FLAMP 1.0.0AM
<FILE 24 583A>20121005120009:paris.txt
<ID 20 D575>W1HKJ Toney, Alabama
<SIZE 13 A46C>{583A}79 3 32
<DATA 40 2801>{583A:1}[b256:start]41
:1LZMA:0:0:0-]:0:
<DATA 40 26A5>{583A:2}0:0:4:08=J-A::3-----==-T--,--?-v
<DATA 23 50DF>{583A:3}:0:0
[b256:end]
<CNTL 5 9016>{EOF}
<CNTL 5 301A>{EOT}

Additional header information

Programs using this protocol may add information both preceding and trailing the protocol blocks.  For example:
QST QST de W1HKJ Toney, Alabama