[nanomsg] Re: The name service for nanomsg
- From: Alex Elsayed <eternaleye@xxxxxxxxx>
- To: nanomsg@xxxxxxxxxxxxx
- Date: Thu, 05 Sep 2013 18:20:14 -0700
On Friday, September 06, 2013 12:37:13 AM Paul Colomiets wrote:
> Hi Dirkjan,
>
> On Fri, Sep 6, 2013 at 12:10 AM, Dirkjan Ochtman <dirkjan@xxxxxxxxxx> wrote:
> > On Thu, Sep 5, 2013 at 5:57 PM, Paul Colomiets <paul@xxxxxxxxxxxxxx>
wrote:
> >> Thoughts?
> >
> > I forget, why can't we just use DNS for this again?
>
> IIRC the main reasons discussed on IRC today are:
>
> 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.
There are other ways to resolve this too, but which one you use depends on the
*task* you are trying to accomplish - the above falls into the mire of asking
"I'm accomplishing X using Y; how do I Y?" (or even just "How do I Y?")
instead of "How can I accomplish X?" - there's a potentially unwarranted
assumption as to mechanism, and insufficient information about the original
goal to receive a good answer.
> 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.
> 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).
> The reference implementation of the service that turns name service
> requests into DNS queries may be written however. It will work for
> some use cases well enough. And the pluggable interface will serve
> much wider number of use cases.
This, too, is an option. DNS is pretty much a perfect match to REQ/REP
semantics anyway - a stateless exchange of a query and an answer; a direct
translation that simply repackages RRs would not be a huge effort from what I
can tell.
Other related posts:
