mirror of
git://scm.dxcluster.org/scm/spider
synced 2024-09-21 15:57:12 +00:00
50f6466ca2
specifically unlocked and so that you don't need to lock the non-SSID call in order to lock an SSID call. So set/lock g1tlh will lock out all instances of g1tlh, g1tlh-1, g1tlh-15 etc except (for instance) unset/lock g1tlh-9. 2. show/lock allows partial callsign matching so sh/lock gb7 will only show GB7* calls that are locked. 3. Had a grand shift around for the start of NP.
214 lines
8.8 KiB
HTML
214 lines
8.8 KiB
HTML
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
|
||
"http://www.w3.org/TR/html4/loose.dtd">
|
||
<html>
|
||
<head>
|
||
<meta http-equiv="Content-Type" content="text/html">
|
||
<title>DXSpider Protocol</title>
|
||
<meta name="Keywords"
|
||
content="DX Cluster, DXSpider, Spider, Packet Cluster, DXCluster, Pavillion Software, AK1A, AX25, AX.25, WWV, Packet Radio, Amateur Radio, Propagation, DX, DXing, G1TLH, GB7TLH, Dirk Koopman, Mailing list, Linux, RedHat, PERL">
|
||
<meta name="Description"
|
||
content="Software and systems for realtime digital communications between amateur radio stations for the provision of information on propagation conditions and stations operating">
|
||
<meta name="Author" content="Dirk Koopman G1TLH">
|
||
<link rel="stylesheet" href="style.css" type="text/css"
|
||
title="default stylesheet">
|
||
</head>
|
||
|
||
<body>
|
||
<hr>
|
||
|
||
<h2>DXSpider Protocol</h2>
|
||
<hr>
|
||
<address>
|
||
<a href="mailto:djk@tobit.co.uk">Dirk Koopman G1TLH</a>
|
||
</address>
|
||
<!-- standard footer -->
|
||
|
||
|
||
<h3>Introduction</h3>
|
||
|
||
<p><br>
|
||
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.</p>
|
||
|
||
<p>This is an attempt at starting again. In fit of originality I am calling
|
||
it "New Protocol" or "NP" for short</p>
|
||
|
||
<h3>Design Criteria</h3>
|
||
<ul>
|
||
<li>The protocol shall be open, published and available for any author to
|
||
use.</li>
|
||
<li>The protocol shall versioned, to allow easy upgrade.</li>
|
||
<li>The protocol shall be layered to allow the use of different transport
|
||
mechanisms (eg: radio, UDP, TCP, multicast).</li>
|
||
<li>Sentences in the protocol shall be capable of being verified as being
|
||
unaltered.</li>
|
||
<li>all sentences shall have an originating node, a serial number and a
|
||
destination. These fields must not be altered by intermediate nodes.</li>
|
||
<li>all sentences shall have similar fields in the same order.</li>
|
||
<li>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').</li>
|
||
<li>There shall be a mechanism for verifying "sensitive" information and/or
|
||
connections.</li>
|
||
</ul>
|
||
|
||
<h3>Definitions</h3>
|
||
<dl>
|
||
<dt><callsign></dt>
|
||
<dd>A callsign can contain the characters [0-9A-Z\-/]. It is always in
|
||
upper case.</dd>
|
||
<dt><nodecall></dt>
|
||
<dd>A callsign of a node. It can contain the same characters as a
|
||
<callsign></dd>
|
||
<dt><origin></dt>
|
||
<dd>The callsign of the originating node, it is a <nodecall>.</dd>
|
||
<dt><destination></dt>
|
||
<dd>The callsign of the destination node, this could be a
|
||
<nodecall> or empty (which implies that this is a broadcast).</dd>
|
||
<dt><touser></dt>
|
||
<dd>The callsign of a user to which this sentence is directed. It is a
|
||
<callsign> or empty.</dd>
|
||
<dt><fromuser></dt>
|
||
<dd>The callsign of the user from which this sentence originally come
|
||
came from. It is a <callsign>.</dd>
|
||
<dt><serial></dt>
|
||
<dd>The serial number of this sentence. It is a number between 0 and
|
||
9999.</dd>
|
||
<dt><time></dt>
|
||
<dd>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.</dd>
|
||
<dt><minutes></dt>
|
||
<dd>The number of minutes since the epoch. This is actually <time>
|
||
/ 60 with no remainder.</dd>
|
||
<dt><flags></dt>
|
||
<dd>A bit field containing various binary values.</dd>
|
||
<dt><digit></dt>
|
||
<dd>A character, representing a numeral, befween '0' and '9'.</dd>
|
||
<dt><hex digit></dt>
|
||
<dd>A character, representing a hexadecimal numeral (a value between
|
||
0->15 [a nibble]), '0'->'9' and 'A'->'F'.</dd>
|
||
<dt><field></dt>
|
||
<dd>A part of a protocol sentence.</dd>
|
||
<dt><freq></dt>
|
||
<dd>A frequency, in kilohertz with an optional (single digit) decimal
|
||
part (ie both 14001 and 14325.1 are valid).</dd>
|
||
<dt><text></dt>
|
||
<dd>Some text in ISO-Latin-1 in both upper and lower case.</dd>
|
||
<dt><cs></dt>
|
||
<dd>A checksum of two <hex digits></dd>
|
||
<dt><cr></dt>
|
||
<dd>A carriage return character (0x0d)</dd>
|
||
<dt><lf></dt>
|
||
<dd>A line feed character (0x0a)</dd>
|
||
</dl>
|
||
|
||
<p></p>
|
||
|
||
<h3>The Protocol</h3>
|
||
|
||
<p></p>
|
||
|
||
<p>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.</p>
|
||
|
||
<p>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>.</p>
|
||
|
||
<p>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'.</p>
|
||
|
||
<p>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.</p>
|
||
|
||
<p>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.</p>
|
||
|
||
<p>All sentences shall have an <origin> and a <destination>
|
||
number. The <destination> can be empty which implies that this sentence
|
||
is to be broadcast. </p>
|
||
|
||
<p>So the generic form of a sentence is:-</p>
|
||
|
||
<p></p>
|
||
|
||
<blockquote class="code">
|
||
QX99|<destination>|<origin>|...|<cs></blockquote>
|
||
|
||
<p></p>
|
||
|
||
<p>Some examples:-</p>
|
||
|
||
<blockquote class="code">
|
||
QX01|GB7TLH|GB7DJK|1|DXSpider:1.48:53.287|90001FFF|5234FE12|DE450A30|F4<br>
|
||
QX01|GB7DJK|GB7TLH|1|DXSpider:1.49:60.45|90002010|AD412458|4532DA56|A1<br>
|
||
QX11||GB7TLH|1|G1TLH|FR0G|164563|14001.1|Easy|53<br>
|
||
QX10||GB7TLH|2|G1TLH|SYSOP|GB7TLH rebooting|4A<br>
|
||
</blockquote>
|
||
|
||
<p></p>
|
||
|
||
<p>Some fields are split further into subfields. The separator character
|
||
shall be ' :' .</p>
|
||
|
||
<p>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).</p>
|
||
|
||
<p></p>
|
||
|
||
<h1>Initialisation</h1>
|
||
|
||
<p>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:-</p>
|
||
|
||
<p><span class="code">QX01|<destination>|<origin>|<protocol
|
||
version>|<software
|
||
info>|<time>|<random>|<challange>|<cs></span> </p>
|
||
|
||
<p>All NP nodes <span style="font-weight: bold">shall<span
|
||
style="font-weight: normal"> use a cryptograph</span></span>ic 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. </p>
|
||
|
||
<p>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.</p>
|
||
|
||
<p>Each sentence that uses a challenge shall include some random element of
|
||
at least 8 characters. The <time> field (if included) is not
|
||
sufficient!</p>
|
||
|
||
<p>Getting back to the initialisation sentence </p>
|
||
<hr>
|
||
<span class="copy">Copyright <20> 2001 by Dirk Koopman G1TLH. All Rights
|
||
Reserved</span>
|
||
<br>
|
||
<span class="id">$Id: index.html,v 1.19 2001/04/17 20:44:11 g0vgs Exp
|
||
$</span></body>
|
||
</html>
|