perl/proto.html

   1 <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML//EN">
   2 <html>
   3   <head>
   4     <title>new protocol</title>
   5   </head>
   6
   7   <body bgcolor="#FFFFFF">
   8     <h2>new protocol</h2>
   9
  10     <hr>
  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 -->
  13 <!-- hhmts start -->
  14 Last modified: Sun Jun 24 02:15:14 BST 2007
  15 <!-- hhmts end -->
  16         <hr>
  17         <h4>Some thoughts</h4>
  18
  19     <ol>
  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
  23                 some kind.
  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.
  29         </ol>
  30
  31         <h4>packet format</h4>
  32
  33         The overall format of a packet shall look like this:-
  34
  35         <p>
  36           <table border=3>
  37                 <tr>
  38                   <td width="20%"><b>Field</b></td>
  39                   <td width="80%"><b>Description</b></td>
  40                 </tr>
  41                 <tr>
  42                   <td width="20%"><b>OP Code</b></td>
  43                   <td width="80%">
  44
  45                         This will be 'B' for now, but will be extended when multicasting
  46                         comes into being, the possible values are:-<br>
  47                         <table>
  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>
  57                         </table>
  58                   </td>
  59                 </tr>
  60                 <tr>
  61                   <td width="20%"><b>From Address</b></td>
  62                   <td width="80%">
  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.
  67                   </td>
  68                 </tr>
  69                 <tr>
  70                   <td width="20%"><b>To Address</b></td>
  71                   <td width="80%">
  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
  75                   </td>
  76                 </tr>
  77                 <tr>
  78                   <td width="20%"><b>Date/Time/Count</b></td>
  79                   <td width="80%">
  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
  83                   </td>
  84                 </tr>
  85                 <tr>
  86                   <td width="20%"><b>Data</b></td>
  87                   <td width="80%">
  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.
  98                   </td>
  99                 </tr>
 100                 <tr>
 101                   <td width="20%"><b>Checksum</b></td>
 102                   <td width="80%">
 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
 108                   </td>
 109                 </tr>
 110           </table>
 111         </P>
 112
 113         <p>
 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.
 120         </p>
 121
 122         <p>
 123           A typical packet might look like:- <br><br>
 124           <code>
 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>
 128       </code>
 129     <p>
 130
 131     <p>
 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.
 138         </P>
 139
 140         <p>
 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
 145           two cluster nodes.
 146     </p>
 147         <br>
 148   </body>
 149 </html>