5 ms·

Location-independent Addressing with Messaging Middleware

7 points by timf 14y ago

zacharyvoase 14y ago
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 14y ago
  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 14y ago
    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 14y ago
So, this seems like a rediscovery of the need for DNS? e: f,b.
- rumcajz 14y ago
  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 14y ago
    DNS has grown the SRV RR to address services. https://tools.ietf.org/html/rfc2782 https://tools.ietf.org/html/rfc2782
    - rumcajz 14y ago
      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 14y ago
        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 14y ago
        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.

7 points by timf 14y ago

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 14y ago
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 14y ago
  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 14y ago

So, this seems like a rediscovery of the need for DNS? e: f,b.

rumcajz 14y ago
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 14y ago
  DNS has grown the SRV RR to address services. https://tools.ietf.org/html/rfc2782 https://tools.ietf.org/html/rfc2782
  - rumcajz 14y ago
    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 14y ago
      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 14y ago
        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.