[nanomsg] Re: The name service for nanomsg

  • From: Martin Sustrik <sustrik@xxxxxxxxxx>
  • To: nanomsg@xxxxxxxxxxxxx
  • Date: Fri, 06 Sep 2013 09:19:34 +0200

On 06/09/13 03:20, Alex Elsayed wrote:

1. If you have a topology  like A -> B-C -> D, where B-C is a device,
how would you distinguish between addresses for A and C?

Assuming this is "multiple sites, connected via devices", many DNS servers
support returning different results based on geolocation of the client's IP
address - this is commonly used by CDNs to pick the nearest one, when IP
anycast via BGP is infeasible.

Yes. This would be useful, especially for large-scale pub/sub topologies. This way the end client can connect to the geographically nearest device in the distribution tree, thus cutting down the overall bandwidth requirements.

2. How would DNS work for inproc sockets?

I honestly see inproc sockets as quite a different problem - for one, moving
from inproc even just to IPC necessitates a *heck* of a lot more changes to
code entirely outside the SP layer than moving from IPC to TCP. It is
architecturally very different, and I don't really see a way that *can* be
cleanly resolved at the naming level, DNS or no - there are too many entirely
unrelated dependencies.
A system that uses inproc has a lot more to worry about than where to get the
names from when it's part of a larger topology.

True. Messing with inproc sockets cannot really be done without recompiling the applications, so it is definitely not a purely administrative task.

Btw, inproc transport is an artifact of nanomsg being implemented in the user space. If it was in kernel space there would be no real difference between IPC and inproc.

3. How would you return protocol to use for connections? (i mean tcp,
ipc, inproc) How would you encode IPC addresses at all?

This one does make a great deal of sense.

SRV would work great if you already know what transport you want
(_myservice._tcp.example.com) and as long as the number of transports are
finite you can just enumerate and look up in parallel (async DNS makes this
less of an issue than it could be).

TXT could work as well, and while it's frowned upon for new protocols the lack
of anything that matches exactly could get you past that in the experimental
stage - until either something is found that works better and doesn't
perpetuate the abuse of TXT records, or is created (see TSIG etc).

My feeling is that if we go with DNS, SRV records won't be sufficient. This, we are left with TXT.

Martin


Other related posts: