

Location-independent Addressing with Messaging Middleware - timf
http://www.250bpm.com/blog:13

======
zacharyvoase
Two things:

1) If you need a central name directory to point to the locations of various
services, we already have DNS and DNS-SD.

2) I've been investigating mDNS+DNS-SD (a.k.a. Bonjour, a.k.a. Avahi) as a
potential solution. One can advertise ØMQ sockets at the host and link-local
level, potentially with forwarding between subnets if you're inclined to
configure it that way.

However, be warned that you shouldn't expose ØMQ sockets over non-trusted
networks. It's still possible to induce bad errors (including aborts and
segfaults) by sending malformed data to an open ØMQ socket.

~~~
rumcajz
We've implemented a DNS-based transport for ZeroMQ, but I am not quite sure it
can be made work especially in WAN environment. DNS propagation delay can take
several days which is not always an option for application names (as opposed
to hostnames).

As for the aborts, I've put all of them there myself, no need to remind me :)

~~~
zacharyvoase
You don't need DNS to propagate across the WAN. Just set up your own root
server. You'll have low-enough load to set near-zero TTLs (or just have a
single root server which everything uses). Although I admit I don't know
enough about your use-case.

------
angersock
So, this seems like a rediscovery of the need for DNS?

e: f,b.

~~~
rumcajz
DNS is basically for resolving the hostnames. You may recall that it
originally evolved from a file containing all the hostnames on the Internet
that people downloaded periodically.

Resolution of service names is a different matter. The authors of the Internet
have solved it in a cheap-and-ugly way by introducing well-known ports.
Unfortunately, the problem wasn't solved in a systematic manner since.

~~~
petersabaini
DNS has grown the SRV RR to address services.
<https://tools.ietf.org/html/rfc2782>

~~~
rumcajz
Yup. The fact, however, is that it is not used widely. My guess here is that
we are facing a problem where requirements differ depending on the scale. We
may want local services to register with DNS automatically as they start and
be reachable within seconds (DNS-SD use case). With the services facing the
outside world, standard pre-defined records with 72hr propagation time are
preferable (RFC2782 use case).

Moreover, I would say there's a need for location-dependent resolving of
service names to limit the availablity of local services, to return a
topologically close instance of the service etc.

All in all, the problem is far from being solved yet.

~~~
rumcajz
To put in simply: At the moment nobody is going to create a DNS record just to
create a TCP connection. Once the following works out of the box on LAN, the
problem can be considered solved:

    
    
        s = socket (AF_INET, SOCK_STREAM, 0);
        bind (s, "myApplication1");
        ...
        s = socket (AF_INET, SOCK_STREAM, 0);
        connect (s, "myApplication1");
    

Propagation of the name outside of the LAN may require additional
administrative work. I guess nobody will complain about that.

~~~
petersabaini
Semi-widely used I'd say. XMPP and SIP come to mind...

What I like about DNS SRV is that it's standardized and relatively simple to
handle, in contrast to some of the other naming schemes out there (eg. CORBA).

I agree though that tools / libraries need to get better here.

