From: minima Date: Tue, 11 Jan 2005 18:56:34 +0000 (+0000) Subject: more WIP X-Git-Tag: 1.53~197 X-Git-Url: http://dxcluster.org/gitweb/gitweb.cgi?a=commitdiff_plain;h=da55cf63b3719d06fe69c76cab566c623d76f04d;p=spider.git more WIP --- diff --git a/techdoc/protocol.pod b/techdoc/protocol.pod index 02388d8e..1e1f2436 100644 --- a/techdoc/protocol.pod +++ b/techdoc/protocol.pod @@ -27,7 +27,7 @@ describes a complete replacement for the PC protocol. It allows a fully looped network, is inherently extensible and should be simple to implement (especially in perl). -All implementations of this protocol shall B use this protocol +All implementations shall use b this protocol for inter-node communications. =head1 DESCRIPTION @@ -36,21 +36,24 @@ This protocol is designed to be an extensible basis for any type of one -> many "instant" line-based communications tasks. -This protocol is designed to be flood routed in a meshed network in +The protocol is designed to be flood routed in a meshed network in as efficient a manner as possible. The reason we have chosen this mechanism is that most L need to be broadcast to allLs. Experience has shown thatLs 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) +nature of the network doesn't lend itself to fixed routing policies. Therefore, +whilst metrics and routing tables (more like routing hint tables) will be +built up over time, an aggressive aging algorithm will also be employed to prevent +a lot of stale routing information being retained. + +Having said that: where routes have +been learned through past traffic, and this data is recent, then direct routing should be used. +Those L that could be routed (likely to be mainly single line one to +one "talk" L) that, anyway, happen sufficiently infrequently that, should they need to be flood routed -(because no route has been learned yet) it is a small cost overall. +(because no route has been learned yet), it is a small cost overall. =head1 Messages @@ -76,30 +79,31 @@ a fairly strict division between Ls and Ls. This protocol attempts to get away from that by deliberately blurring (or, in some cases, removing) any distinction between the two. -Applications that use this protocol are essentially all peers and therefore -nodes the only real difference between Ls and Ls is that a "node" has one or more +Applications that use this protocol are essentially all peers and therefore the +only real difference between Ls and Ls is that a node has one or more listeners running that will, potentially, allow incoming connections from other Ls, Ls or Ls. These routable entities are called Ls. -Any application that is a sink and/or source of data for Ls; is capable of obeying +Any application that is a sink and/or source of data; is capable of obeying the protocol message construction rules and understands how to deduplicate incoming messages correctly can operate as a routeable entity or L in this protocol. It is called an L. An L is called a L if it accepts connections from Ls and is -prepared to route messages on their behalf to other Ls or L. In addition it -may provide some other, usually simpler, interface (eg simple telnet access) for direct user access. +prepared to route messages on their behalf to other Ls or Ls. In addition it +may provide some other, usually simpler, interface (eg simple telnet access) for direct user access. Acting +in the protocol, on their behalf. The concept of an L has been invented because modern clients are -capable of being intelligent than simple -character based connections such as telnet or ax25. They wish to be able to +capable of being more intelligent than simple +character based connections such as telnet or ax25. They also 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 application implementing the L. +(i.e. in this protocol) and leave +the human presentation to the application. It also helps to modularise the various interfaces that may be implemented such as the legacy, character based connections of existing PC protocol based nodes. @@ -169,7 +173,8 @@ will get to the other side of a mesh of Ls. There may be a discontinuity either caused by outage or deliberate filtering. However, as it is envisaged that most L will be flood routed or, -in the case of directed L (those that have L that is a callsign down some/most/all interfaces showing a route for that +in the case of directed L (those that have a L containing a L of some kind) +down some/most/all interfaces showing a route for that direction, it is unlikely that L will be lost in practice. Assuming that there is a path between all the Ls in a network, then it is guaranteed @@ -332,7 +337,7 @@ duplicated! # a talk (actually 'text') message to a user (some distance away # from the origin node) - GB7TLH,G8TIC,3D03450019,3,G1TLH|THiya Mike what's happening? + GB7TLH,G8TIC,3D03450019,3,G1TLH|T,Hiya Mike whats happening? # a talk/chat/text message to a Group GB7TLH,VHF,0413525F23,2,G1TLH|T,2m is opening on MS