[Dxspider-support] node & user information

Dirk Koopman djk at tobit.co.uk
Mon Jan 16 17:25:02 GMT 2017


Hopefully this will answer your recent questions...

Thank you for your answers.

There are PC92 (A) add, (D) delete and (C) node config records.

PC92 A & D records are delayed for (as default and from memory) one 
minute before sending. There are two reasons for this:

1) It means that programs that connect, fire dx (and maybe do a couple 
of others things automatically) then disconnect do not cause PC92 
records to be sent.
2) By waiting some time, the updates (both add and delete) accrete and 
all the changes sent in just one A and/or D record.

It is the A and D records that cause a very large proportion of the 
traffic.

The node config (C) records are a different kettle of fish. They are 
normally sent once every four hours and, in one (sometimes HUGE) record 
represents the true connection state of a node. This is really a node's 
backstop "definitive" list of nodes and users to cope with inadequate 
lossy links and, more importantly a means of newly (re)started nodes 
getting a cluster configuration within a reasonable period. The default 
used to be 30 minutes or so and that was quickly changed when it became 
apparent that this was waaaaay too frequent for 400+ nodes sending 500 
-> 3000+ byte C records. one could think of this in disk backup terms 
with the C record being a full backup of a node's config and A & D 
records being incremental updates. Increasing the frequency of the C 
records will, very quickly, become a problem - just by themselves.

In principle one could switch off the A and D records and only lose the 
"realtime" (or incrementally updated) configuration.

Just for completeness there are PC92 (K) records which are similar to 
the old PC50 records with some additional information on software and 
version numbers. They are sent once an hour and are used as remote node 
"keepalive" notices. If a node doesn't hear any PC92 traffic (A,C,D or 
K) for three hours then that node and its user connections is removed 
from local copy of the cluster configuration.

Also, as it stands, if one sends a talk message out to a callsign that 
is not in the  node's view pf the cluster map, then it is flood routed 
anyway. This is very much analogous to a "ping".

Dirk

On 10/01/17 20:45, Martin Davies G0HDB via Dxspider-support wrote:
> On 3 Jan 2017 at 12:09, Dirk Koopman via Dxspider-support wrote:
>
>> While I am in a development mood, I would like to address the issue of
>> node and user broadcasts. The question is this:
>>
>> 1. Do we need to know whether and where users are connected?
>>
>> 2. If yes to 1), do we need to know in (approximately) real time?
>>
>> 3. What about nodes?
>>
>> The issues are that PC92 user and node connection information takes up
>> the majority of the bandwidth that DXSpider uses. I contend that it
>> would be cheaper to flood route talk messages and "personal" mail (if
>> anyone actually uses that any more) and switch off PC92 "add" (A) and
>> "delete" (D) messages than carry on as we are. That would leave us with
>> PC92 "config" (C) and "ident" (K) messages. Even C messages could be
>> dispensed with and user location inferred from other traffic (like
>> spots/chat/announces). Another option might be to only use A and D
>> messages for nodes.
>>
>> Discuss
> Hello Dirk (and all), re: the discussion points about the dissemination of node and user
> information throughout the Cluster, here are my thoughts...
>
> 1.  Do we need to know whether and where users are connected - ideally yes, so that a
>      user can easily see who else is connected either to their local node or to another
>      node.  For example, I might want to initiate a 'talk' with another user and if I have no
>      way of knowing whether or not that user is connected to a node in the Cluster then I
>      would be 'firing blind' if I tried to send a talk (or other form of message) to the other
>      user.  The suggestion of flood-routing talk messages (and mail messages) is OK but I
>      would prefer to be able to find out beforehand if a user is actually connected before
>      generating a talk to him/her.
>
> 2.  Do we need to know, in near-real time, when a node or a user connects to or
>      disconnects from the Cluster - probably not.  I fully understand the network bandwidth
>      and other problems that can arise from having the PC92 messages, especially the A
>      and D flavours, flying around the Cluster so it definitely seems sensible to take a look
>      at how these traffic volumes could be reduced.  Perhaps an alternative to the
>      near-real time dissemination of user adds and deletes would be for a node to only
>      provide details of its connected users on demand, for example when someone
>      somewhere does a 'show/conf' or a 'show/sta' command.  Alternatively perhaps a
>      node could broadcast a list of its connected users every few (eg. 5) minutes - the
>      volumes of such traffic would hopefully be much lower than the incessant flood of
>      PC92A's and PC92D's that exists at present and would still enable a reasonably
>      up-to-date list of all connected users to be maintained by all nodes throughout the
>      Cluster.
>
> 3.  The option of restricting PC92A's and PC92D's to node adds and deletes would be
>      fine if there's another means of querying/maintaining the list of users connected to a
>      node - see 2. above.
>
> I hope this is helpful; feel free to shoot the ideas down in flames if you think they're rubbish!
>
> --
> 73, Martin G0HDB
>
>
> ---
> This email has been checked for viruses by Avast antivirus software.
> https://www.avast.com/antivirus
>
>
> _______________________________________________
> Dxspider-support mailing list
> Dxspider-support at dxcluster.org
> http://mailman.tobit.co.uk/mailman/listinfo/dxspider-support




More information about the Dxspider-support mailing list