From 11056ea11fce910aa0e0d183a1cce73cf0de1c21 Mon Sep 17 00:00:00 2001 From: djk Date: Sat, 4 Sep 1999 21:48:12 +0000 Subject: [PATCH] *** empty log message *** --- perl/proto.html | 137 ++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 137 insertions(+) create mode 100644 perl/proto.html diff --git a/perl/proto.html b/perl/proto.html new file mode 100644 index 00000000..b0328de4 --- /dev/null +++ b/perl/proto.html @@ -0,0 +1,137 @@ + + + + new protocol + + + +

new protocol

+ +
+
Dirk Koopman G1TLH

+ + +Last modified: Sat Sep 4 22:49:36 BST 1999 + +
+

Some thoughts

+ +
    +
  1. The protocol must be capable of being multi/broadcast. +
  2. The format must regular. +
  3. All packets will have a to, from and date field and a checksum of + some kind. +
  4. space is a premium, therefore I am prepared to break layering rules + in specific cases to avoid duplicating fields. E.g. in AX25 using + callsign fields as part of the data (which means reconstructing the + packets from ax25 to be like you expect) +
  5. the protocol will continue to be ascii for simplicity of use. +
+ +

packet format

+ + The overall format of a packet shall look like this:- + +

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
FieldDescription
OP Code + This will be 'B' for now, but will be extended when multicasting + comes into being +
From Address + This will always be the originating cluster callsign and shall + never be changed +
To Address + The To address can be anything at all that is likely + to be meaningful to a cluster program, it could be a callsign, a 'group' name of + some sort (eg 6MUK) or it could be empty, indicating a broadcast +
Date/Time/Count + This is a unix time_t, in hex (ie 8 characters) with an optional + 2 byte hex count on the end which can allow up to 256 protocol messages to be originated + a second. Programs must allow for both 8 or 10 digit hex numbers +
Data + The actual cluster data. The data in this field can contain only + ascii data. Any non ascii data shall be converted to %XX format, where + XX is the hex equivalent of the character represented, certain special + characters in the data such as '%', '|' and '^' shall also be converted. Although + it is envisaged that most data will be ascii, things like mail files can and + will contain newline characters and these will be converted. +

It is suggested that the raw version of the data in this packet be no + more than 128 characters, if it any packets are likely to be routed over + ax25 bearers. However, programs should be prepared to accept 1024 characters (after + decoding) for point to point wire links and routed data. +
Checksum + This is calculated as the simple arithmetic checksum, modulo 256, + of the whole packet excluding + this field and any preceeding field separator, as two hex digits + this checksum is designed solely to pick up errors in any connections between + this protocol and lower layers - where hopefully real CRC checking is done +
+

+ +

+ Each field in the above packet shall be separated by the '|' character EXCEPT the + op code which is concatenated onto the from field. The '|' character + must not appear in any field in the overall packet, it is the data providers responsibility + make sure this happens. If it is necessary for operations there can be a locally generated + newline sequence added on the end of the packet for sending or delimiting purposes + which is stripped off before presenting the packet for decoding. +

+ +

+ A typical packet might look like:-

+ + BGB7DJK||8BCF65DE|DX^G1TLH^M0BAA^144123^Humungous Signal!|A8
+ BGB7DJK|SYSOP|8BCF65FC|AN^G1TLH^What @$%7C%5E!** condxs?|5C
+ BGB7DJK|GB7BAA|8BCF670102|TA^G1TLH^G8TIC^Baaaaaaaaaaa|FD
+ +

+ +

+ As mentioned earlier, astute readers will see that there is a mix up of lower + layer data with higher. This is deliberate (as well as potentially messy), but it saves + characters and promotes regularity on format. Apart from anything else, most directed + data actually needs to pass from cluster to cluster and it is important for the higher + layers to know where a packet originated. Also higher layers need to address packets to + other clusters or groups and there would otherwise be considerable duplication. +

+ +

+ If a packet fails a checksum, then it is silently dropped - for now. When reliable + multicast comes in, other actions will occur at this level. In any event, higher level + functions that require some state to be maintained between packets (eg mail transfer) + should make their own arrangements in case reliable multicast isn't available between + two cluster nodes. +

+
+
+ Document Id: $Id$ + + -- 2.34.1