(as Bradley pointed out on the mailing list, he's willing to do the development to fix this.)

It does seem that we should talk about this some more as NDB has been going in another direction.

I think we already support mDNS (for cast devices), but that seems to work for multiple ips only, not for multiple ports on the same ip.

Alexey might have some thoughts.

What direction has NDB (unknown acronym?) been going in / is it something I could take instead of mDNS?

ping / would this be faster for me to just submit a mDNS based CL?

I am somewhat confused. mDNS is used to resolve the host, while you know the host already. It seems like the problem you are trying to solve is orthogonal to what mDNS is for.

My understanding is that mDNS implies a responder per host. In your case, subprocesses share the host, hence it would require a shared agent/daemon responder. That's exactly what NDB does. Alexey should be able to share his ndb example in the following week, so hang on. It targets your use case precisely.

I might be mistaking wrt mDNS details, so if my understanding above is not correct, please let us know.

mDNS can support https://en.wikipedia.org/wiki/SRV_record or https://en.wikipedia.org/wiki/TXT_record both of which can show the port number of the service that mDNS is trying to discover.

You can use mDNS over UDP broadcast and so you don't need a shared daemon.

Also, what is NDB? https://www.npmjs.com/package/ndb is 7 years old???

>> mDNS can support https://en.wikipedia.org/wiki/SRV_record or https://en.wikipedia.org/wiki/TXT_record both of which can show the port number of the service that mDNS is trying to discover.

These are just DNS extensions, they don't address the concern from comment #6. Let me put it simply, who listens on the 5353/UDP in your set up?

The process(es) running `node --inspect`, since it is UDP there could be multiple.

I assume there is a node-side change that is going to augment the subprocess creation with the code that propagates child ports to the root process? So your root node process is your "agent" aware of multiple node processes then. Something along these lines, but slightly better organized is what Alexey should share with you. It has no relation to the npm package you refer to.

there doesn't need to be a root process, UDP broadcasts can be replied to by many processes. 

the only change would be to listen for UDP broadcasts in the same process as `--inspect`.

As per https://tools.ietf.org/html/rfc6762#page-43, what you want to do does not work and is discouraged.

That limitation and mitigation are if the incoming packet is using unicast instead of multicast? I'm not sure I follow. Per the discouraged comment, I don't see anything except on https://tools.ietf.org/html/rfc6762#section-14 which comments on uniqueness and multiple interfaces, we are not seeking uniqueness nor using multiple interfaces.

>> Per the discouraged comment, I don't see anything except on https://tools.ietf.org/html/rfc6762#section-14

Hm. Are we reading the same spec? My link has the following section that reads loud and clear as far as what should be done and what should not:

==========================================
15.4.  Recommendation

   Because of these issues, this document encourages implementers to
   design systems with a single Multicast DNS implementation that
   provides Multicast DNS services shared by all clients on that
   machine, much as most operating systems today have a single TCP
   implementation, which is shared between all clients on that machine.
   Due to engineering constraints, there may be situations where
   embedding a "user-level" Multicast DNS implementation in the client
   application software is the most expedient solution, and while this
   will usually work in practice, implementers should be aware of the
   issues outlined in this section.
==========================================

- So I understand what they recommend and why
- I don't see the engineering constraints that would make us go explicitly against the recommendation
- Let alone that your proposal seems to also misuse mDNS to discover local services on a known host

Given the above, I'd suggest to not go against the spec recommendation. We also have a better alternative that does not require messing with the broadcasting: protocol's Target domain allows service discovery and seems to be more appropriate given the problem. With that, I'm closing this request.