[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