Location-independent Addressing with Messaging Middleware
1–10 of 10 posts
Re: Location-independent Addressing with Messaging Middleware
#2Two 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.
Re: Location-independent Addressing with Messaging Middleware
#3Two 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 exp…
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 :)
Re: Location-independent Addressing with Messaging Middleware
#4So, this seems like a rediscovery of the need for DNS?
e: f,b.
Re: Location-independent Addressing with Messaging Middleware
#5So, this seems like a rediscovery of the need for DNS? e: f,b.
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.
Re: Location-independent Addressing with Messaging Middleware
#6So, this seems like a rediscovery of the need for DNS? e: f,b.
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.
DNS has grown the SRV RR to address services. https://tools.ietf.org/html/rfc2782
Re: Location-independent Addressing with Messaging Middleware
#7Earlier quoted context omitted.
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.
DNS has grown the SRV RR to address services. https://tools.ietf.org/html/rfc2782
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.
Re: Location-independent Addressing with Messaging Middleware
#8Earlier quoted context omitted.
DNS has grown the SRV RR to address services. https://tools.ietf.org/html/rfc2782
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). Moreove…
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");
Re: Location-independent Addressing with Messaging Middleware
#9Earlier quoted context omitted.
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). Moreove…
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 gu…
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.
Re: Location-independent Addressing with Messaging Middleware
#10Two 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 exp…
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.