[Cluster-tech] PC9x

[Dirk Koopman]

Lee Sawkins wrote:
> Hi Dirk
> 
> Ok, ok, now I think I understand, finally.
> 
> The "C" records only apply to the callsign immediately after the "C". 
> There are mixed users and nodes in the list, but they are all connected
> to the node after the "C".  The users don't apply to the immediately
> preceeding node in this list.  That is what I thought before.  

The callsign after the PC92 is the originating node of the PC92.

The callsign after the A D or C is the node callsign the rest of the 
sentence applies to.

You should be aware that I am making some major changes under your feet.

The first is that C records for PC9x capable nodes will only happen 
about once every 18-24 hours. C records for dependent non-PC9x nodes 
will be sent every 90-120 mins. Both of these intervals are deliberately 
random within the range specified. PC9x nodes are now sufficiently 
reliable to not need hourly C records. However, see below for some 
heuristics...

As a consequence of this, I need a different mechanism to age out the 
routing tables. Can't remember whether I explained this to you earlier. 
Once an hour each node's routing table entry's obscount is decremented. 
If a C record comes in, it is reset back to 3. If it ever drops below 0 
(which means that 3 hours have passed since a C record has been seen), 
the node is removed from the table and, here is the difficult bit: the 
consequences passed onto any dependent old style PC protocol nodes.

So I have chosen an old sentence: PC50. I shall increase the interval at 
which a PC50 is sent (we don't really need to worry about netrom 
connections timing out anymore) to every 45-60 mins (again randomly) and 
it will continue to have an obscount (pump up count) of 3. Any PC50 
received resets the respective routing table obscount back to 3.

Also, you should be a aware that I have added some space saving measures:

1. On C records: only the node in the first slot will have version 
information. This is to reinforce the notion that a node is responsible 
for distributing *its* information, it ain't anyone else's job other 
than to transmit it onward unchanged. It also saves some space.

2. On A and D records: the first slot can (and when I am reasonably 
certain most people are up to date enough - will) be empty, as in

    PC92^GB7DJK^12345^A^^1G1TLH^H99

This is a shortcut for:

    PC92^GB7DJK^12345^A^GB7DJK^1G1TLH^H99

Please make provision for this.

3. On A and D records: There have always been the 'login', 'have a quick 
look around', 'logoff' merchants. But I see that there is now code out 
there that, instead of 'looking around', fires a command (usually a 
spot) and then logs off - all in less than a second.

As a consequence of this, and also because the whole PC92 thing 'builds 
up' a routing table (and PC93 talk is now broadcastable if necessary), I 
have decided to "slug" the fact that people login and logout for a 
default period of 60secs (twiddle pot available, can be switched off). 
This means that if you login and logoff within the period, you won't 
appear in a PC92. It isn't very sophisticated, there is just one global 
timer and a hash table per attached node which splurges out its content 
once a minute. So if you login at 59 secs and logout at 3 secs you will 
still generate and A and D record, but login at 3 and out at 15 and you 
will not.

This also saves quite a bit on a busy node with lots of users (think 
ED7ZAB), simply because people are logging in and out all the time and 
you can send just the one A and D per minute for the "delta changes" 
instead of religiously one per user.

> 
> Sorry to be such a bother.
> 

NP

Dirk