X-Git-Url: http://www.dxcluster.org/gitweb/gitweb.cgi?a=blobdiff_plain;f=techdoc%2Fprotocol.pod;h=3c3ccdcc4af5bb5539d17b4600ecd5851a4380ef;hb=7046b8ba37863c3040cee17e46d100675e720eaf;hp=5ea94c6642c0ecd73a5977673ff6006fc146e8ac;hpb=7ee1dd3cf4163dff242b737c2b5293235a9fa24b;p=spider.git diff --git a/techdoc/protocol.pod b/techdoc/protocol.pod index 5ea94c66..3c3ccdcc 100644 --- a/techdoc/protocol.pod +++ b/techdoc/protocol.pod @@ -1,6 +1,6 @@ =head1 NAME -DXSpiderWeb Orthogonal Communications Protocol +Aranea Orthogonal Communications Protocol $Revision$ @@ -31,25 +31,77 @@ for inter-node communications. =head1 DESCRIPTION -This protocol is encoded in UTF8 with HTTP style escaping. It is -designed to be an extensible basis for any type of one to many +This protocol is +designed to be an extensible basis for any type of one too many "instant" line-based communications tasks. This protocol is designed to be flood routed in a meshed network in -as efficient a manner as possible. +as efficient a manner as possible. The reason we have chosen this +mechanism is that most L need to be broadcast to all nodes. + +Experience has shown that nodes will appear and (more infrequently) +disappear without much (or any) notice. +Therefore, the constantly changing and uncoordinated +nature of the network doesn't lend itself to fixed routing policies. + +Having said that: directed routing is available where routes have +been learned through past traffic. +Those L that could be routed (mainly single line one to +one "talk" L) +happen sufficiently infrequently that, should they need to be flood routed +(because no route has been learned yet) it is a small cost overall. + +=head1 Messages + +A message is a single line of UTF8 encoded and HTTP escaped text +terminated in the standard internet manner with a . Each message consists of a L and a L. -The two sections are separated with the '|' character and the whole -message is terminated in the standard RFC/Internet manner with the -ascii characters. It follows that these -characters (as well as a small number of other reserved characters) +The two sections are separated with the '|' character. +It follows that these +characters (as well as non-printable characters, , and +a small number of other reserved characters) can only be sent escaped. This is described further in the -L. +L and L. Most of this document is concerned with the L, however some L which all implementation should issue and must accept are described. +=head1 Applications + +In the past messaging applications such as DX Cluster software have maintained +a fairly strict division between "nodes" and "users". This protocol attempts +to get away from that distinction by allowing any entity to connect to any +other. + +Applications that use this protocol are essentially all peers and therefore +nodes the only real difference between a "node" and a "user" (using this +protocol) is that a "node" has one or more listeners running that will, +potentially, allow incoming connections. A "user" simply becomes an end +point that never uses the L or L slots in the +L. + +The reason for this is that modern clients are more intelligent than simple +character based connections such as telnet or ax25. They wish to be able to +distinguish between the various classes of message, such as: DX spots, +announces, talk, logging info etc. It is a pain to have to do it, as now, +by trying to make sense of the (slightly different for each piece of node +software) human readable "user" version of the output. Far better to pass on +regular, specified, easily computer decodable versions of the message, +i.e. in this protocol, and leave +the human presentation to the client software. + +Having said that, the protocol allows for traditional, character based, +connections, as in the past. But it is up to applications +to service and control that type of connection and to provide human readable +"user" output. + +One of the legacy, character based connections that will probably have to be +serviced is that of existing PC protocol based nodes. They should be treated +as local clients, B as peers in this protocol. It is likely that, in order +to do this, some extra Ls will need to be defined at application level. + =head1 Routing Section The application that implements this protocol is essentially a line @@ -58,7 +110,7 @@ effectively a datagram. It is assumed that nodes are connected to each other using a "reliable" streaming protocol such as TCP/IP or -AX25. Having said that: in context, messages in this protocol could be +AX25. Having said that: in context, L in this protocol could be multi/broadcast, either "as is" or wrapped in some other framing protocol. @@ -67,10 +119,10 @@ through your node" protocol, there is no guarantee that a message will get to the other side of a mesh of nodes. There may be a discontinuity either caused by outage or deliberate filtering. -However, as it is envisaged that most messages will be flood routed or, -in the case of directed messages (those that have L and/or +However, as it is envisaged that most L will be flood routed or, +in the case of directed L (those that have L and/or L fields) down some/most/all interfaces showing a route for that -direction, it is unlikely that messages will be lost in practice. +direction, it is unlikely that L will be lost in practice. =head2 Field Description @@ -137,7 +189,7 @@ neighbouring nodes must increment this field before passing it on to higher layers for onward processing. Implementations may have an upper limit to this field and may -silently drop incoming messages with a L count greater than the +silently drop incoming L with a L count greater than the limit. =item B @@ -223,7 +275,7 @@ tuple. The basic system will learn which interfaces can see what nodes by looking at the tuple and merging that with the L count. Each interface remembers the latest L with the lowest L for each L that arrives on that interface. It also remembers -the number of messages for that L that has been received on +the number of L for that L that has been received on that interface. Any message for onward broadcast is duplicated and sent out on all @@ -255,8 +307,8 @@ duplicated! =head2 Examples # on link startup from GB7BAA (both sides hello) - GB7TLH,3D02350001,0,GB7BAA|HELLO,Aranea,1.2,24.123 - GB7BAA,3D02355421,1,GB7TLH|HELLO,Aranea,1.1,23.245 + GB7TLH,3D02350001,0|HELLO,Aranea,1.2,24.123 + GB7BAA,3D02355421,1|HELLO,Aranea,1.1,23.245 # on user startup to GB7TLH GB7TLH,3D042506F2,0,G1TLH|HELLO,PClient,1.3 @@ -323,7 +375,7 @@ vertical bar '|', percent '%', equals '=' and non printable characters less than 127 (or %7F in hex) -[including newline and carraige return] are tranlated to +[including newline and carraige return] are translated to their two hex digit equivalent preceeded by the percent '%' character. For example: @@ -341,7 +393,7 @@ are written according to this specification must say: use UTF8; A message (or line) is terminated with -0x0d 0x0a. Incoming messages must be accepted even when terminated +0x0d 0x0a. Incoming L must be accepted even when terminated with just . Care must be taken to make sure that fields have any reserved characters