[Dxspider-support] Chat Filter

Dirk Koopman djk at tobit.co.uk
Tue Jul 6 10:04:34 BST 2004


On Tue, 2004-07-06 at 02:06, Lee Sawkins wrote:
> Perhaps this is something Dirk could solve.
> 
> Maybe by modifying the internode PC12 protocol messages that are sent
> between nodes.   That way the messages could hopefully propagate to all
> Dx Clusters, not just Dx Spider.  It would require coordination between
> the various cluster authors to make it work for their software but I
> don't think it should break anything if they don't do anything.

Strangely, I *am* working on this. Unfortunately the likelihood of all
cluster software authors getting it together to agree on what PC12
fields mean are frankly: nil. You obviously have a better understanding
of what is going on than most.

However, what I currently do (AFAIK) is nominally compatible with (or at
least doesn't break) vanilla AK1A.
 
> 
> The PC12 messages (announcements) have a flag that is 0 for "to All"
> announces and 1 for "Wx" announces.  I don't think this flag is used for
> anything else.  What I propose is for it to be set to say 2 for "named"
> announces.  This "name" would replace the "*" in the PC12 field that is
> used for "pc node call" in AK1A software.  It is the second field of the
> PC12 message.  I believe this field is always "*" now.  This name could
> include such things such as "IOTA" or anything else.  The nodes could
> process these PC12s and send local announces "To IOTA" or whatever. 

If you have a good look at a PC12 you will see that there are actually
three address slots. Normally (and I am simplifying here because
addresses get shuffled around) that '*' is replaced with something like
'IOTA.LST' and does the same job as me putting 'IOTA' in there. The
difference is that a sysop has to manually edit a file (called: iota.lst
:-) and add callsigns to it for those calls to receive messages to IOTA.

Unfortunately, no other cluster software (that I know of) can handle a
non '*' in that field.

Experiments have shown that setting 'flag' fields to unexpected values
tend to make other software crash. So that, in my view, is a non
starter.

> 
> While we are at it, why not have a flag of 3 and use it for a sort of
> broadcast talk message.  The "name" field would have the call of the
> destination.  When a node matches this call with a local user, it would
> then send him the message and not send the PC12 to any further nodes. 
> This may help eliminate some to All announces.


This is actively being worked on. I finished rewriting the routing code
last night. I now have to get it all working again. Once that is done
what will happen is that DXSpider nodes will pass routing information
(on a different basis to now) in PC59 frames amongst themselves. The big
difference being that now DXSpider nodes will be able to tell where
nodes are connected (or not). Also there are periodic 'my config'
broadcasts (once an hour, currently) that reset information for a node.
This should stop the current nonsense carried in the routing tables. 

Once this is up and working, I will introduce a semi routed/broadcast
talk (probably a PC58) which will do talks and chat. This will mean that
talks will be sent down all possible routes (if visible) or broadcast if
not. Chat, of course, will be broadcast.

This is, in addition (probably), to a severe curtailment of the amount
of routing information that a node will accept from a 'legacy' node.
This should also bring the routing tables back to something approaching
reality. 

Now, I am also preparing to allow a user to receive (cut down) PC
protocol if they desire (ie everything except routing). This is to make
people like yourself's job a bit easier writing user programs. Either
that or someother similar protocol that provides easily machine
decodable versions of the user data. Please Discuss.

Dirk G1TLH  
-- 
Please Note: Some Quantum Physics Theories Suggest That When the
Consumer Is Not Directly Observing This Message, It May Cease to
Exist or Will Exist Only in a Vague and Undetermined State.





More information about the Dxspider-support mailing list