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.
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 :)
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.
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.
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.
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.
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.
9 comments
[ 3.1 ms ] story [ 34.4 ms ] thread1) 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.
As for the aborts, I've put all of them there myself, no need to remind me :)
e: f,b.
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.
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.
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.