User: Password:
|
|
Subscribe / Log in / New account

0MQ: A new approach to messaging

0MQ: A new approach to messaging

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

Reminds me of the messaging API of the Chorus microkernel that I once used (in the last century).
I wonder if 0MQ also has a notion similar to msgboxes or "ports" (a la Mach) also? At the time, I found this (endpoint-related) object to be pretty useful too. And yes, I was very fond of messaging abstractions like these at that time.


(Log in to post comments)

0MQ: A new approach to messaging

Posted Jan 21, 2010 19:31 UTC (Thu) by sustrik (guest, #62161) [Link]

What I've found at Wikipedia is that Mach port is "a "port" defines a secure pipe for IPC between tasks".

If so, there's new IPC transport in recent version of 0MQ. It works on top of UNIX domain sockets, so I'm not sure you would consider it "secure".

0MQ: A new approach to messaging

Posted Jan 21, 2010 21:18 UTC (Thu) by ortalo (subscriber, #4654) [Link]

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]

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 (subscriber, #964) [Link]

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 (subscriber, #313) [Link]

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


Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds