Re: [boost] 0MQ messaging in Boost
James Mansion wrote:
This component would be much higher level than anything else in Boost, except perhaps quickbook and the preprocessor.
I think it should be considered, but with some caution. What is the intended approach to on-the-wire etc - is it going to be rewritten as an amqp 1.0 system, for example?
These are good questions. 0MQ is high-level in some respects but it is not a competitor to Qpid or OpenAMQ, it's a brokerless library that is fully integrated into client apps. The new 0MQ API looks simply like a socket that can pass messages between points. The wire level protocol is very simple, it does not compare with AMQP (which I'm well aware of, being one of the original designers). You can check the 0MQ protocol (SPB) here: http://rfc.zeromq.org/. One of our projects was to integrate 0MQ with AMQP, but as a very thin and fast client stack. Thus, it would work with OpenAMQ, Qpid, RabbitMQ and in fact provide Boost apps with a fast way to use AMQP networks. There's an experimental branch that does this. @Yigong Liu, regarding Channel: you're definitely looking at the same questions as us. 0MQ perhaps has more focus on performance, it aims at markets where latency has to be in the microseconds. There is also the intention of implementing more complex messaging patterns, but those tend to need brokers. Concretely, we'll: * Look at making 0MQ with Asio * Make the 0MQ licensing work for Boost * Make a proof of concept showing Boost working with 0MQ Which should make things more concrete. Cheers Pieter
Hi, Pieter Hintjens wrote:
The wire level protocol is very simple, it does not compare with AMQP (which I'm well aware of, being one of the original designers). You can check the 0MQ protocol (SPB) here: http://rfc.zeromq.org/.
Indeed very simple. Being BLOB-based it does not handle binary format differences (byte ordering, anyone?) between platforms. I would not therefore describe the whole solution as "high-level". A high-level solution - and the one that is reasonably portable - would need to be coupled/supplemented with serializer/deserializer, which actually already exists in Boost. In this context the integration with Boost would indeed make it an interesting exercise, except for the fact that the Boost serialization library is not very fast. My personal and humble opinion is that such a couple would fall out of your intended/typical benchmarks. How would you promote it then? Who would constitute the target audience? Regards, -- Maciej Sobczak * www.msobczak.com * www.inspirel.com
------- Original message -------
From: Pieter Hintjens <ph@imatix.com> To: boost@lists.boost.org Sent: 30.7.'09, 8:05
[snip]
Concretely, we'll:
Can the protocol be separate from the user API? Specially with asio integration. So that the client can extend the library to use other protocols with or without a broker.
* Look at making 0MQ with Asio * Make the 0MQ licensing work for Boost * Make a proof of concept showing Boost working with 0MQ
Which should make things more concrete.
Cheers Pieter
-- Felipe Magno de Almeida Sent from my Nokia E71
Yes, integrating with Asio is absolutely necessary. FYI, Channel uses Interprocess.MessageQueue for connections among the processes in the same node and Asio.socket to connectt processes in different nodes. Channel is a framework to build peer-peer messageing systems, can be used to build the broker based or broker-less systems in your terms. When two channels are connected thru "streams" either based on shared memory message queue or asio socket, their name-space or message ids are exchanged and synchronized so that "transparent" distributed message passing can be achieved. Glad to see more messaging proposals coming up:) Regards Yigong
* Look at making 0MQ with Asio * Make the 0MQ licensing work for Boost * Make a proof of concept showing Boost working with 0MQ
participants (4)
-
Felipe Magno de Almeida -
Maciej Sobczak -
Pieter Hintjens -
Yigong Liu