new protocol

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

Field	Description
OP Code	This will be 'B' for now, but will be extended when multicasting comes into being, the possible values are:- A ACK B Broadcast C Catch up J Join L Leave M Multicast N NAK P Point to Point T Time (ping with time)
From Address	This will always be the originating (cluster) callsign and shall never be changed. The word cluster is in brackets because it is envisaged that 'connected' callsigns will eventually speak the the same protocol as the clusters.
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.