DXSpider Protocol

Introduction

For some time now it has become obvious that the original AK1A protocol has become stretched to beyond breaking point. Some attempts have been made to extend it, but none have done what is actually required: which is to throw it away completely and start from scratch.

This is an attempt at starting again. In fit of originality I am calling it "New Protocol" or "NP" for short

Design Criteria

The protocol shall be open, published and available for any author to use.
The protocol shall versioned, to allow easy upgrade.
The protocol shall be layered to allow the use of different transport mechanisms (eg: radio, UDP, TCP, multicast).
Sentences in the protocol shall be capable of being verified as being unaltered.
all sentences shall have an originating node, a serial number and a destination. These fields must not be altered by intermediate nodes.
all sentences shall have similar fields in the same order.
sentences shall be in latin-1 and must not contain any characters other than those between 0x20 and 0x7e. Any characters outside of this range will be HTML escaped (viz: converted into the form '%', hex digit, hex digit; eg: carriage return (0x0d) is converted to '%0D').
There shall be a mechanism for verifying "sensitive" information and/or connections.

Definitions

<callsign>: A callsign can contain the characters [0-9A-Z\-/]. It is always in upper case.
<nodecall>: A callsign of a node. It can contain the same characters as a <callsign>
<origin>: The callsign of the originating node, it is a <nodecall>.
<destination>: The callsign of the destination node, this could be a <nodecall> or empty (which implies that this is a broadcast).
<touser>: The callsign of a user to which this sentence is directed. It is a <callsign> or empty.
<fromuser>: The callsign of the user from which this sentence originally come came from. It is a <callsign>.
<serial>: The serial number of this sentence. It is a number between 0 and 9999.
<time>: A time in standard 'time_t' format, the number of seconds since 00:00 1st Jan 1970 (the 'epoch'), the output of the standard system 'time()' subroutine call in both unix and MS-Dos/Windows.
<minutes>: The number of minutes since the epoch. This is actually <time> / 60 with no remainder.
<flags>: A bit field containing various binary values.
<digit>: A character, representing a numeral, befween '0' and '9'.
<hex digit>: A character, representing a hexadecimal numeral (a value between 0->15 [a nibble]), '0'->'9' and 'A'->'F'.
<field>: A part of a protocol sentence.
<freq>: A frequency, in kilohertz with an optional (single digit) decimal part (ie both 14001 and 14325.1 are valid).
<text>: Some text in ISO-Latin-1 in both upper and lower case.
<cs>: A checksum of two <hex digits>
<cr>: A carriage return character (0x0d)
<lf>: A line feed character (0x0a)

The Protocol

Each protocol line is separate and distinct and is called a "sentence". This is a "datagram" style protocol. Each protocol line is called a "sentence" and begins with the string "QX" in upper case, followed by two digits. The sentence is terminated by a <cr> or a <lf> character or both. Internally, the terminating characters should be discarded completely and the sentence processed without.

The character set used shall be ISO-Latin-1, with only the characters 0x20 -> 0x7e permitted within a sentence. All other characters shall be "HTML Escaped" which is that they shall be replaced by the three character scheme of '%', <hex digit>, <hex digit>.

The sentence is split up into <fields> which are delimited by the '|' character (0x7c). If the '|' character occurs within a <field> it shall be replaced by the string '%7C'.

There is no intrinsic maximum length of a sentence. Having said that, there will be some underlying maximum lengths implied by the transport mechanisms employed. Because one of those transport mechanisms is likely to be AX25 in UI mode. It is recommended that broadcast sentences shall be no more than 200 bytes in length.

All sentences shall have a <checksum> in a separate <field> at the end. The checksum is simply the sum, modulo 256, of all the characters of the sentence except for the final <field> separator and the two <hex digits> of the checksum itself. The purpose of the checksum is to check that no intermediate node has changed the sentence. It is assumed that the underlying transport mechanisms will deal with communications errors.

All sentences shall have an <origin> and a <destination> number. The <destination> can be empty which implies that this sentence is to be broadcast.

So the generic form of a sentence is:-

QX99|<destination>|<origin>|...|<cs>

Some examples:-

QX01|GB7TLH|GB7DJK|1|DXSpider:1.48:53.287|90001FFF|5234FE12|DE450A30|F4
QX01|GB7DJK|GB7TLH|1|DXSpider:1.49:60.45|90002010|AD412458|4532DA56|A1
QX11||GB7TLH|1|G1TLH|FR0G|164563|14001.1|Easy|53
QX10||GB7TLH|2|G1TLH|SYSOP|GB7TLH rebooting|4A

Some fields are split further into subfields. The separator character shall be ' :' .

Some sentences will have serial numbers associated with them which functions both as a generation number and as an aid to deduplication. The particular usage for each type of sentence is discussed later, but the general form will be as a modulo 10000 number (0-9999).

Initialisation

When a node wishes to speak NP it shall send a "QX01" initialisation sentence to the other node on connection. It does not wait, it connects and sends. Both sides of the connection send simultaniously and symetrically. The fields currently in this sentence are:-

All NP nodes shall use a cryptographic challenge to determine that the node that they are talking to is correct. In this protocol, wherever a challenge is mandated, the challenge field will be the last field before the checksum and shall include the whole of the sentence upto that point as the "salt" to that challenge.

Because we are not yet sufficiently paranoid to include full crytography, we will use the standard 32 bit CCITT CRC algorithm on a shared secret phrase, each side shall have a different phrase each known to both sides. Each connection shall have a different pair of phrases. Each phrase shall be at least 40 characters long.

Each sentence that uses a challenge shall include some random element of at least 8 characters. The <time> field (if included) is not sufficient!

Getting back to the initialisation sentence