Project

General

Profile

Support #21074

Create ACNET node MCDPMD

Added by Richard Neswold 12 months ago. Updated 12 months ago.

Status:
Assigned
Priority:
Normal
Category:
Protocol
Target version:
-
Start date:
10/09/2018
Due date:
% Done:

0%

Estimated time:
Duration:

Description

The ACNET node tables contain several entries associated with multicast addresses. These entries provide a shared channel of communication instead of referring to a single computer. acnetd defines MCAST internally as the multicast address 239.128.4.1. As of this writing, the node table contains these other multicast nodes1:

Node Name Multicast Address
DNLDD 239.128.4.1
NODES 239.128.4.1
STATES 239.128.4.2
UCD 239.128.4.4
DBNEWS 239.128.4.7
MCSETS 239.128.4.8

Right now, all DPM clients are using MCAST to do service discovery which means every ACNET node is receiving those messages when only 8 (currently) need to. We used to have a multicast node, DPMD, but removed it2. I think I'd like to have a new, multicast node, MCDPMD, and have DPM and its clients use it.

To avoid disruption:

  • Create the node MCDPMD and associate it with an unused multicast address.
  • Modify the DPM code to create a MCDPMD handle and only use it to process service discovery messages.
  • Restart all the DPMs. When they create their MCDPMD handle, acnetd will join the MCDPMD multicast group. acnetd will still be listening to the MCAST address, so current DPM client requests will still work.
  • Convert client libraries to use the new node address so that only the DPM nodes will see the flood of discovery requests.

Concerns, comments are welcome.


1 It makes sense that NODES and MCAST have the same multicast address. DNLDD should probably have its own, unique address, however.

2 The way multicast support works in acnetd is, if your handle matches a multicast node name, acnetd joins the multicast. The other side effect is that acnetd allows multiple clients to use the same multicast handle. This is why we deprecated the DPMD node name; because multiple clients can appear on a given node as DPMD and you wouldn't have a way to give one of the clients your DPM request.

History

#1 Updated by Richard Neswold 12 months ago

  • Status changed from New to Assigned

Ah, crap. As I wrote the description, the request evolved from "Reinstate DPMD" to "Create MCDPMD", but I didn't update the subject of the issue. Sorry for the additional noise.

#2 Updated by Richard Neswold 12 months ago

  • Subject changed from Reinstate ACNET node DPMD to Create ACNET node MCDPMD

#3 Updated by Richard Neswold 12 months ago

Added Tim to the watch list.

#4 Updated by Timothy Zingelman 12 months ago

Network group documentation shows:
239.128.4.3 as ACNET lookup service
239.128.4.5 as NML clock (on 50090 not 6801)
239.128.4.6 as Requests to STATES
Are any of these known to be unused currently?

#5 Updated by Richard Neswold 12 months ago

NML Clock isn't in the ACNET node table because it's outside the ACNET protocol (i.e. it's not using port 6801) so it's still valid. The look-up service was abandoned for the same reason as DPM; multiple clients could use the handle on a given node and make the service unreliable. I'll let Charlie decide if he wants to make a similar change to the LOOKUP service as we're trying to do for DPM. I don't know what "requests to STATES" means. Brian? Jim? (The fact that neither are in the node table makes me think they're unused.)



Also available in: Atom PDF