Try to reduce the no of duplicate PC92C for external PC protocol
nodes by listening for others that are out there and bumping up our
update time instead of us transmitting more or less the same info
as well.
add optional INET6 capability. Need to load CPAN modules
You will need IO::Socket::INET6 to use INET6 capability.
Also I have enabled PC92 slugging and set it to 1 minute as default.
Also I have put code in to handle empty first node slots in PC92.
Wait for a period of time before issuing pc92a or d records
and then aggregate them together as a collection of adds or deletes
in just (up to) two sentences, instead of one per event.
This has the side effect of (nearly) eliminating the "login, fire a
spot, logoff" merchants.
restore talk "<call> not visible on cluster" message
Restore the message if the <call> is not routable. However, instead
of the old behaviour of then just stopping dead, it now sends the
message anyway as a broadcast.
Since the beginning I have had set/isolate be unidirection, so that I could
see the far node's config, but he could not see mine. This is too confusing
for yer modern sysop and I have now made it such that only the local configs
are remembered, regardless of what is sent back to me. I.e. it is now
symmetric and bidirectional.
try to make sure that local nodes take precedence over external ones
There seems to be a problem with localnodes sometimes being overridden by
data from external PC92 data. Usually (but not always) data for local
PC19 nodes being overridden by data from other PC92 with the same node
connected.
Also put in a frig for the sysop announce problem.
This should stop pc93 conversions which are sent out a) being redisplayed
and b) as SYSOP. It may also stop all these strange chat messages to
unlikely chat group names.
Also rewritten chat import routines for new regime.
Dirk Koopman [Fri, 29 Jun 2007 13:29:13 +0000 (14:29 +0100)]
try to make set/isolate more bombproof.
Add a set/wantpc9x (default = on) command. It is likely
that (apart from mistakes) you will want to unset it mostly.
If either this flag == 0 or the node is isolated then pc9x
will not be offered on the PC18 and PC9x's will be ignored.
Dirk Koopman [Sun, 24 Jun 2007 20:15:23 +0000 (21:15 +0100)]
connect up the discontinuous trees and route better
This involves making sure that all the external nodes get fixed
up even though their parent node does not yet exist (because no
config record has come in. It is safe to create these, in
anticipation of the C record coming in somewhen.
In the process of this, obscount reseting now happens much more
frequently (which I hope means correctly).
Allow Route::findroutes to find routes to these disconnected
nodes that are in the routing table but have no parent that is
yet anchored to a dxchan. Simply remember the dxchan that that
C record came in on. It doesn't matter if it gets overwritten by
another node, if it came in that way, there must be a route.
In any case, chances are, the first dxchan to get the C record
is the best and the deduping will (mostly) prevent it being
overwritten. When the linking C record comes in, it is all
irrelevant anyway...
Dirk Koopman [Sat, 23 Jun 2007 11:54:02 +0000 (12:54 +0100)]
Rearrange startup PC92 arrangements
This is an attempt to cut down on the number PC92Cs that are flying
around. It does this be storing the last PC92C and only sending
it (which should be ignored by other people if broadcast) and
a PC92A. It does mean that the PC92C could be quite out of date
but a fresher will be along soon(ish)
I have also increase the pc92 update time to one hour and
randomised it to one hour - upto 1/4 of the update time.
It will also do each node separately, rather than all together in
one big gob.