[nanomsg] Re: The name service for nanomsg
- From: Martin Sustrik <sustrik@xxxxxxxxxx>
- To: nanomsg@xxxxxxxxxxxxx
- Date: Sat, 07 Sep 2013 07:42:14 +0200
On 06/09/13 12:00, Kaspar Schiess wrote:
The example appeared in this thread: A -> B-C -> D (B-C is a device)
How would you distinguish A and C ? If you think one can bind an other
can connect. Consider the following:
A -> B-C -> D-E -> F
At first, one would have a simple topology, A consuming a service from
D. So A needs to know an address that resolves to D for its connect,
let's call that a1.
Then an admin decides to interpose the device B-C. He modifies a1 to
return B. He also comes up with another address for D (a2). This is what
C connects to.
and so on.
So really, what you need for this is a table saying
a1 B
a2 D
The question is: What exactly is a1?
Let's assume we use programmer-defined socket name for that purpose.
So, admin starts N instances of application A, each checks a1 entry in
DNS, gets an address and connects to it. So far so good.
Now imagine that the admin wants some of the instances (say those
located in an oversees office) to connect to a local device rather than
directly to global hub D. He starts device B but now he has no way to
tell *some instances* of A to connect to B instead of D. He can either
re-direct them all, or none of them.
The conclusion is that using someting simple like socket name is not
sufficient for administration of a complex topology.
> Yes. Look at how DNS SRV works. It gives a list of addresses with
> priorities and weights.
Ah - for load balancing. Still, that would only mean that the table
would need to map a1 to more than just B, let's say a name resolves to
more than one string.
The requirement of being able to specify bind vs. connect is still
pulled out of thin air. I don't see the real world use of that.
Ok, imagine pub/sub topology over TCP. Some components bind, others
connect. Now we want to change the transport to multicast (say PGM).
With multicast the very concept of bind vs. connect doesn't apply. What
happens is that everyone connects. But given that bind was hardcoded in
the application, the transition isn't possible without re-compilation.
> The decision of bind vs connect is also admin's task not a
> programmer's one, so it should be in name service rather than code.
Really? Is it? The admin would have to know quite a bit about the code
to be able to take the decision of connecting somewhere vs. having
connects be made. Which makes him a programmer in my book.
Let's define the individual roles here:
1. Programmer. The guy who writes and compiles the application.
2. Application admin. The guy who starts all the processes in the
production environment and keeps it working.
3. Network admin. The guy who sets up the network and ensures it is
functional.
We are talking about "application admin" in this thread, not the
"network admin".
Martin
Other related posts:
