[Cluster-tech] PC92
Dirk Koopman
djk at tobit.co.uk
Wed Sep 19 01:18:17 CEST 2007
Lee
I am making some important changes to PC92 handling, in the light of
experience, to try to further reduce the amount of traffic.
I want, over a period of time, to increase the period that C records are
broadcast, for the main node, to once in 24 hours. It simply isn't
necessary to do it any more frequently now. C records for connected
legacy nodes will continue to be sent once an hour.
However, that then gives us a problem with ageing out old node records.
So I have come up with the PC92 K (for keepalive) record. To be send out
for the main and dependent nodes once an hour (with the usual 15 minutes
of randomness taken off).
Two examples are given below:-
22:50:34 -> D GB7DJK PC92^GB7TLH^82234^K^5GB7TLH:5454^3^1^H99^
22:59:04 -> D WR3D PC92^GB7TLH^82744^K^7GB7DJK-1:5453^1^1^H99^
The first for the main PC9X handling node and the second for an attached
legacy PC protocol node. The two fields at the end are <no of nodes> and
<no of users> respectively. At some point in the future this might be
the basis of some kind of '-EXT' protocol. I may even use this, rather
than a C record, as part of the initial PC18/PC20/PC22 exchange.
You will note the similarity of this and the traditional PC50.
The reason I can contemplate these changes is because what happens now,
on connection of a node, is that a 15 minute timer is started, which
causes a *new* C record to be generated and broadcast when it expires.
Currently, on connection, only the last C record generated (which may
eventually be up to 24 hours old) is sent. Whilst we were updating
every hour, this was not too bad, but if we go to 24 hours it will be
too silly.
You should note that on node connection the 15 min timer is reset, even
if it is already running so, on start up (for instance) when there is a
big flurry of connecting, the C record is delayed until all the node
connection activity has died out (for at least 15 mins).
Also on the legacy node connections, since they tend to be connected to
the PC9X cloud in several places, we currently get several copies of
their C record, one for each node connection to the cloud. I have added
a simple heuristic so that if am due to send my version, and I have seen
one in the last 30 minutes from somewhere else, I don't bother sending
mine, but still update my timer so that I can make the decision again
later. This cuts down the superfluous C records quite a bit!
Now all I have to do (when I have merged back all these changes into the
main line) is get people to update... Sigh...
Dirk
More information about the Cluster-tech
mailing list