1 <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML//EN">
4 <title>new protocol</title>
7 <body bgcolor="#FFFFFF">
11 <address><a href="mailto:djk@tobit.co.uk"></a>Dirk Koopman G1TLH</address><br>
12 <!-- Created: Sat Sep 4 21:11:44 BST 1999 -->
14 Last modified: Sat Sep 4 23:50:50 BST 1999
17 <h4>Some thoughts</h4>
20 <li>The protocol must be capable of being multi/broadcast.
21 <li>The format must regular.
22 <li>All packets will have a to, from and date field and a checksum of
24 <li>space is a premium, therefore I am prepared to break layering rules
25 in specific cases to avoid duplicating fields. E.g. in AX25 using
26 callsign fields as part of the data (which means reconstructing the
27 packets from ax25 to be like you expect)
28 <li>the protocol will continue to be ascii for simplicity of use.
31 <h4>packet format</h4>
33 The overall format of a packet shall look like this:-
38 <td width="20%"><b>Field</b></td>
39 <td width="80%"><b>Description</b></td>
42 <td width="20%"><b>OP Code</b></td>
45 This will be 'B' for now, but will be extended when multicasting
46 comes into being, the possible values are:-<br>
48 <tr><td>A</td><td>ACK</td></tr>
49 <tr><td>B</td><td>Broadcast</td></tr>
50 <tr><td>C</td><td>Catch up</td></tr>
51 <tr><td>J</td><td>Join</td></tr>
52 <tr><td>L</td><td>Leave</td></tr>
53 <tr><td>M</td><td>Multicast</td></tr>
54 <tr><td>N</td><td>NAK</td></tr>
55 <tr><td>P</td><td>Point to Point</td></tr>
56 <tr><td>T</td><td>Time (ping with time)</td></tr>
61 <td width="20%"><b>From Address</b></td>
63 This will always be the originating (cluster) callsign and shall
64 <emph>never</emph> be changed. The word cluster is in brackets because
65 it is envisaged that 'connected' callsigns will eventually speak the
66 the same protocol as the clusters.
70 <td width="20%"><b>To Address</b></td>
72 The <i>To</i> address can be anything at all that is likely
73 to be meaningful to a cluster program, it could be a callsign, a 'group' name of
74 some sort (eg <tt>6MUK</tt>) or it could be empty, indicating a broadcast
78 <td width="20%"><b>Date/Time/Count</b></td>
80 This is a unix time_t, in hex (ie 8 characters) with an optional
81 2 byte hex count on the end which can allow up to 256 protocol messages to be originated
82 a second. Programs must allow for both 8 or 10 digit hex numbers
86 <td width="20%"><b>Data</b></td>
88 The actual cluster data. The data in this field can contain only
89 ascii data. Any non ascii data shall be converted to <tt>%XX</tt> format, where
90 <tt>XX</tt> is the hex equivalent of the character represented, certain special
91 characters in the data such as '%', '|' and '^' shall also be converted. Although
92 it is envisaged that most data will be ascii, things like mail files can and
93 will contain newline characters and these will be converted.
94 <br><br>It is suggested that the raw version of the data in this packet be no
95 more than 128 characters, if it any packets are likely to be routed over
96 ax25 bearers. However, programs should be prepared to accept 1024 characters (after
97 decoding) for point to point wire links and routed data.
101 <td width="20%"><b>Checksum</b></td>
103 This is calculated as the simple arithmetic checksum, modulo 256,
104 of the whole packet excluding
105 this field and any preceeding field separator, as two hex digits
106 this checksum is designed solely to pick up errors in any connections between
107 this protocol and lower layers - where hopefully real CRC checking is done
114 Each field in the above packet shall be separated by the '|' character <b>EXCEPT</b> the
115 <tt>op code</tt> which is concatenated onto the <tt>from</tt> field. The '|' character
116 must not appear in any field in the overall packet, it is the data providers responsibility
117 make sure this happens. If it is necessary for operations there can be a locally generated
118 newline sequence added on the end of the packet for sending or delimiting purposes
119 which is stripped off before presenting the packet for decoding.
123 A typical packet might look like:- <br><br>
125 BGB7DJK||8BCF65DE|DX^G1TLH^M0BAA^144123^Humungous Signal!|A8<BR>
126 BGB7DJK|SYSOP|8BCF65FC|AN^G1TLH^What @$%7C%5E!** condxs?|5C<BR>
127 BGB7DJK|GB7BAA|8BCF670102|TA^G1TLH^G8TIC^Baaaaaaaaaaa|FD<BR>
132 As mentioned earlier, astute readers will see that there is a mix up of lower
133 layer data with higher. This is deliberate (as well as potentially messy), but it saves
134 characters and promotes regularity on format. Apart from anything else, most directed
135 data actually needs to pass from cluster to cluster and it is important for the higher
136 layers to know where a packet originated. Also higher layers need to address packets to
137 other clusters or groups and there would otherwise be considerable duplication.
141 If a packet fails a checksum, then it is silently dropped - for now. When reliable
142 multicast comes in, other actions will occur at this level. In any event, higher level
143 functions that require some state to be maintained between packets (eg mail transfer)
144 should make their own arrangements in case reliable multicast isn't available between