]> www.dxcluster.org Git - spider.git/blob - html/newprot.html
show git branch in show/version
[spider.git] / html / newprot.html
1 <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
2     "http://www.w3.org/TR/html4/loose.dtd">
3 <html>
4 <head>
5   <meta http-equiv="Content-Type" content="text/html">
6   <title>DXSpider Protocol</title>
7   <meta name="Keywords"
8   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">
9   <meta name="Description"
10   content="Software and systems for realtime digital communications between amateur radio stations for the provision of information on propagation conditions and stations operating">
11   <meta name="Author" content="Dirk Koopman G1TLH">
12   <link rel="stylesheet" href="style.css" type="text/css"
13   title="default stylesheet">
14 </head>
15
16 <body>
17 <hr>
18
19 <h2>DXSpider Protocol</h2>
20 <hr>
21 <address>
22   <a href="mailto:djk@tobit.co.uk">Dirk Koopman G1TLH</a>
23 </address>
24 <!-- standard footer -->
25
26
27 <h3>Introduction</h3>
28
29 <p><br>
30 For some time now it has become obvious that the original AK1A protocol has
31 become stretched to beyond breaking point. Some attempts have been made to
32 extend it, but none have done what is actually required: which is to throw it
33 away completely and start from scratch.</p>
34
35 <p>This is an attempt at starting again. In fit of originality I am calling
36 it "New Protocol" or "NP" for short</p>
37
38 <h3>Design Criteria</h3>
39 <ul>
40   <li>The protocol shall be open, published and available for any author to
41     use.</li>
42   <li>The protocol shall versioned, to allow easy upgrade.</li>
43   <li>The protocol shall be layered to allow the use of different transport
44     mechanisms (eg: radio, UDP, TCP, multicast).</li>
45   <li>Sentences in the protocol shall be capable of being verified as being
46     unaltered.</li>
47   <li>all sentences shall have an originating node, a serial number and a
48     destination. These fields must not be altered by intermediate nodes.</li>
49   <li>all sentences shall have similar fields in the same order.</li>
50   <li>sentences shall be in latin-1 and must not contain any characters other
51     than those between 0x20 and 0x7e. Any characters outside of this range
52     will be HTML escaped (viz: converted into the form '%', hex digit, hex
53     digit; eg: carriage return (0x0d) is converted to '%0D').</li>
54   <li>There shall be a mechanism for verifying "sensitive" information and/or
55     connections.</li>
56 </ul>
57
58 <h3>Definitions</h3>
59 <dl>
60   <dt>&lt;callsign&gt;</dt>
61     <dd>A callsign can contain the characters [0-9A-Z\-/]. It is always in
62       upper case.</dd>
63   <dt>&lt;nodecall&gt;</dt>
64     <dd>A callsign of a node. It can contain the same characters as a
65       &lt;callsign&gt;</dd>
66   <dt>&lt;origin&gt;</dt>
67     <dd>The callsign of the originating node, it is a &lt;nodecall&gt;.</dd>
68   <dt>&lt;destination&gt;</dt>
69     <dd>The callsign of the destination node, this could be a
70       &lt;nodecall&gt; or empty (which implies that this is a broadcast).</dd>
71   <dt>&lt;touser&gt;</dt>
72     <dd>The callsign of a user to which this sentence is directed. It is a
73       &lt;callsign&gt; or empty.</dd>
74   <dt>&lt;fromuser&gt;</dt>
75     <dd>The callsign of the user from which this sentence originally come
76       came from. It is a &lt;callsign&gt;.</dd>
77   <dt>&lt;serial&gt;</dt>
78     <dd>The serial number of this sentence. It is a number between 0 and
79     9999.</dd>
80   <dt>&lt;time&gt;</dt>
81     <dd>A time in standard 'time_t' format, the number of seconds since 00:00
82       1st Jan 1970 (the 'epoch'), the output of the standard system 'time()'
83       subroutine call in both unix and MS-Dos/Windows.</dd>
84   <dt>&lt;minutes&gt;</dt>
85     <dd>The number of minutes since the epoch. This is actually &lt;time&gt;
86       / 60 with no remainder.</dd>
87   <dt>&lt;flags&gt;</dt>
88     <dd>A bit field containing various binary values.</dd>
89   <dt>&lt;digit&gt;</dt>
90     <dd>A character, representing a numeral, befween '0' and '9'.</dd>
91   <dt>&lt;hex digit&gt;</dt>
92     <dd>A character, representing a hexadecimal numeral (a value between
93       0-&gt;15 [a nibble]), '0'-&gt;'9' and 'A'-&gt;'F'.</dd>
94   <dt>&lt;field&gt;</dt>
95     <dd>A part of a protocol sentence.</dd>
96   <dt>&lt;freq&gt;</dt>
97     <dd>A frequency, in kilohertz with an optional (single digit) decimal
98       part (ie both 14001 and 14325.1 are valid).</dd>
99   <dt>&lt;text&gt;</dt>
100     <dd>Some text in ISO-Latin-1 in both upper and lower case.</dd>
101   <dt>&lt;cs&gt;</dt>
102     <dd>A checksum of two &lt;hex digits&gt;</dd>
103   <dt>&lt;cr&gt;</dt>
104     <dd>A carriage return character (0x0d)</dd>
105   <dt>&lt;lf&gt;</dt>
106     <dd>A line feed character (0x0a)</dd>
107 </dl>
108
109 <p></p>
110
111 <h3>The Protocol</h3>
112
113 <p></p>
114
115 <p>Each protocol line is separate and distinct and is called a "sentence".
116 This is a "datagram" style protocol. Each protocol line is called a
117 "sentence" and begins with the string "QX" in upper case, followed by two
118 digits. The sentence is terminated by a &lt;cr&gt; or a &lt;lf&gt; character
119 or both. Internally, the terminating characters should be discarded
120 completely and the sentence processed without.</p>
121
122 <p>The character set used shall be ISO-Latin-1, with only the characters 0x20
123 -&gt; 0x7e permitted within a sentence. All other characters shall be "HTML
124 Escaped" which is that they shall be replaced by the three character scheme
125 of '%', &lt;hex digit&gt;, &lt;hex digit&gt;.</p>
126
127 <p>The sentence is split up into &lt;fields&gt; which are delimited by the
128 '|' character (0x7c). If the '|' character occurs within a &lt;field&gt; it
129 shall be replaced by the string '%7C'.</p>
130
131 <p>There is no intrinsic maximum length of a sentence. Having said that,
132 there will be some underlying maximum lengths implied by the transport
133 mechanisms employed. Because one of those transport mechanisms is likely to
134 be AX25 in UI mode. It is recommended that broadcast sentences shall be no
135 more than 200 bytes in length.</p>
136
137 <p>All sentences shall have a &lt;checksum&gt; in a separate &lt;field&gt; at
138 the end. The checksum is simply the sum, modulo 256, of all the characters of
139 the sentence except for the final &lt;field&gt; separator and the two &lt;hex
140 digits&gt; of the checksum itself.  The purpose of the checksum is to check
141 that no intermediate node has changed the sentence. It is assumed that the
142 underlying transport mechanisms will deal with communications errors.</p>
143
144 <p>All sentences shall have an &lt;origin&gt; and a &lt;destination&gt;
145 number. The &lt;destination&gt; can be empty which implies that this sentence
146 is to be broadcast. </p>
147
148 <p>So the generic form of a sentence is:-</p>
149
150 <p></p>
151
152 <blockquote class="code">
153   QX99|&lt;destination&gt;|&lt;origin&gt;|...|&lt;cs&gt;</blockquote>
154
155 <p></p>
156
157 <p>Some examples:-</p>
158
159 <blockquote class="code">
160   QX01|GB7TLH|GB7DJK|1|DXSpider:1.48:53.287|90001FFF|5234FE12|DE450A30|F4<br>
161   QX01|GB7DJK|GB7TLH|1|DXSpider:1.49:60.45|90002010|AD412458|4532DA56|A1<br>
162   QX11||GB7TLH|1|G1TLH|FR0G|164563|14001.1|Easy|53<br>
163   QX10||GB7TLH|2|G1TLH|SYSOP|GB7TLH rebooting|4A<br>
164 </blockquote>
165
166 <p></p>
167
168 <p>Some fields are split further into subfields. The separator character
169 shall be ' :' .</p>
170
171 <p>Some sentences will have serial numbers associated with them which
172 functions both as a generation number and as an aid to deduplication. The
173 particular usage for each type of sentence is discussed later, but the
174 general form will be as a modulo 10000 number (0-9999).</p>
175
176 <p></p>
177
178 <h1>Initialisation</h1>
179
180 <p>When a node wishes to speak NP it shall send a "QX01" initialisation
181 sentence to the other node on connection. It does not wait, it connects and
182 sends. Both sides of the connection send simultaniously and symetrically. The
183 fields currently in this sentence are:-</p>
184
185 <p><span class="code">QX01|&lt;destination&gt;|&lt;origin&gt;|&lt;protocol
186 version&gt;|&lt;software
187 info&gt;|&lt;time&gt;|&lt;random&gt;|&lt;challange&gt;|&lt;cs&gt;</span> </p>
188
189 <p>All NP nodes <span style="font-weight: bold">shall<span
190 style="font-weight: normal"> use a cryptograph</span></span>ic challenge to
191 determine that the node that they are talking to is correct. In this
192 protocol, wherever a challenge is mandated, the challenge field will be the
193 last field before the checksum and shall include the whole of the sentence
194 upto that point as the "salt" to that challenge. </p>
195
196 <p>Because we are not yet sufficiently paranoid to include full crytography,
197 we will use the standard 32 bit CCITT CRC algorithm on a shared secret
198 phrase, each side shall have a different phrase each known to both sides.
199 Each connection shall have a different pair of phrases. Each phrase shall be
200 at least 40 characters long.</p>
201
202 <p>Each sentence that uses a challenge shall include some random element of
203 at least 8 characters. The &lt;time&gt; field (if included) is not
204 sufficient!</p>
205
206 <p>Getting back to the initialisation sentence  </p>
207 <hr>
208 <span class="copy">Copyright © 2001 by Dirk Koopman G1TLH. All Rights
209 Reserved</span>
210  <br>
211 <span class="id">$Id$</span></body>
212 </html>