Dirk Koopman [Fri, 16 Nov 2007 17:15:11 +0000 (17:15 +0000)]
add time constraints and other checks on PC9x timestamp
This involves making sure that the timestamp is within 15 mins of "now"
to be accepted. This has other rollover effects in that I don't send an
"old" C record on startup anymore, just send an A record followed by a K.
These days a newly minted C record will be along in 15mins or so anyway.
Dirk Koopman [Wed, 10 Oct 2007 10:45:59 +0000 (11:45 +0100)]
push non-pc9x and non-spider nodes back for routing
At the moment it appears that we can rely on non-spider nodes routing
stuff correctly for mail and rcmd. So we push those routes to the back
of the list.
Added the new K record for keepalives.
Increased the PC92 C interval to 24 hours.
Increased dependent node C interval to 2 hours.
PC50 can reset obs.
PC50 now routed everywhere without filters except isolation,
this may change back in time, when K record is ubiquitous.
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...