0MQ: A new approach to messaging

Posted Jan 21, 2010 21:18 UTC (Thu) by ortalo (guest, #4654)
In reply to: 0MQ: A new approach to messaging by sustrik
Parent article: 0MQ: A new approach to messaging

Hmmm, I had forgotten this security-orientation of Mach ports. But that was not the thing that I was thinking to.
What I found nice in Chorus API was the fact that msgboxes (IIRC the name) - ie. communications endpoints - acquired in one thread (process) were encaspulating all the queuing, buffering, parameters and error signaling from the application level. So, for example, you could rely on them for holding message(s), properly ordering error reports or interrupts with messages anterior to errors, etc.
A nice feature too (but primarily system-wide) was that these msgboxes were simple system-wide IDs. In a distributed or concurrent application, initialization was therefore very straighforward: processes send their msgboxes IDs to each other. Hence, it was pretty easy to write/start complex applications without relying too much on correct static configurations (of various TCP/UDP port numbers for example).
Well, maybe I over-emphasize this (nostalgia...;-). 0MQ sockets seems to offer a nice encapsulation too from what I see of the API documentation. And real multicast support is not so common...

Do you think it would be possible to find a (clean&generic) way to get rid of explicit transport selection in zmq_bind() - or am I just dreaming?

0MQ: A new approach to messaging

Posted Jan 22, 2010 7:27 UTC (Fri) by sustrik (guest, #62161) [Link] (3 responses)

That's pretty interesting question. We've done a lot of experimenting about how to provide location transparency (using symbolic rather than physical addresses in bind & connect).

At the moment the idea is that symbolic name resolving can be offloaded to the DNS. Also recall that domain name resolving (at least on Linux) doesn't mean DNS alone. You can hook into it quite easily. You can even plug in an LDAP server, so you can define your endpoints in a directory service. Anyway, the whole topic needs more thinking and design work.

0MQ: A new approach to messaging

Posted Jan 22, 2010 15:42 UTC (Fri) by mato (guest, #964) [Link] (2 responses)

Using DNS for locating 0mq services would be very cool. Martin, I don't know if you're aware but DNS can store many record types, so we could invent a format for 0mq service records and then implement something like dns://service.example.com for lookup which would grab the appropriate record and decode that into a proper transport://endpoint.

Something to discuss on the dev list...

0MQ: A new approach to messaging

Posted Jan 22, 2010 18:31 UTC (Fri) by sustrik (guest, #62161) [Link]

Sound just too cool to be true :) Let's move this discussion to the mailing list.

0MQ: A new approach to messaging

Posted Jan 22, 2010 18:32 UTC (Fri) by dlang (guest, #313) [Link]

why not use one of the existing resource/service record definitions?