fully looped network, is inherently extensible and should be simple
to implement (especially in perl).
-All implementations of this protocol shall B<only> use this protocol
+All implementations shall use b<only> this protocol
for inter-node communications.
=head1 DESCRIPTION
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</Messages> need to be broadcast to allL</Node>s.
Experience has shown thatL</Node>s 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</Messages> that could be routed (mainly single line one to
-one "talk" L</Messages>)
+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</Messages> that could be routed (likely to be mainly single line one to
+one "talk" L</Messages>) 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
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 L</Node>s and L</User>s is that a "node" has one or more
+Applications that use this protocol are essentially all peers and therefore the
+only real difference between L</Node>s and L</User>s is that a node has one or more
listeners running that will,
potentially, allow incoming connections from other L</Node>s, L</Endpoint>s or L</User>s. These
routable entities are called L</Terminal>s.
-Any application that is a sink and/or source of data for L</Group>s; 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</Terminal> in this protocol. It is called an L</Endpoint>.
An L</Endpoint> is called a L</Node> if it accepts connections from L</Endpoint>s and is
-prepared to route messages on their behalf to other L</Node>s or L</Endpoint>. 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 L</Node>s or L</Endpoint>s. 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</Endpoint> 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</Endpoint>.
+(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.
discontinuity either caused by outage or deliberate filtering.
However, as it is envisaged that most L</Messages> will be flood routed or,
-in the case of directed L</Messages> (those that have L</Group> that is a callsign down some/most/all interfaces showing a route for that
+in the case of directed L</Messages> (those that have a L</Group> containing a L</Terminal> of some kind)
+down some/most/all interfaces showing a route for that
direction, it is unlikely that L</Messages> will be lost in practice.
Assuming that there is a path between all the L</Node>s in a network, then it is guaranteed
# 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
projects / spider.git / commitdiff