Esteban, die mq in 0mq is misleading here because it is not a message queue. 0mq is called sockets on stereoids where you can plug communication channels with less overhead. It is more of an orchestration toolkit for distributed computing. Norbert
Am 07.10.2014 um 20:54 schrieb Esteban A. Maringolo <emaringolo@gmail.com>:
Marten,
I keep a close eye to MQ based architectures, because somehow they feel "the best way" to implement interprocess/service messaging. And also because I always wanted to implement something based on message queues, just for the sake of it. :)
However I don't find them suitable for interactive bidirectional communication, but instead as their name suggest, queues. Ideally for asynchronous communication, a "fire and forget" way of messaging. If you go by the MQ path Sven implemented STAMP [1], which can work with RabbitMQ's adapter [2]
Unless you have an evented/callback based subscription to a queue, the polling and message consumption from the queue itself will consume about similar CPU cycles. What you gain using MQ is that you can offload computation to other "worker images".
Regards!
[1] https://github.com/svenvc/docs/blob/master/neo/stamp.md [2] http://www.rabbitmq.com/stomp.html Esteban A. Maringolo
2014-10-07 15:18 GMT-03:00 itlists@schrievkrom.de <itlists@schrievkrom.de>:
I have a little different view. lpgl is no real problem for me - it may be used for non-open-soure stuff without problems. Therefore I see no real problems with that.
The other thing is: speed. And here it might differ a lot. I had written a heavy communication server in Smalltalk and with about 30 clients the Smalltalk process was CPU bound. No way to go.
Introducing 0MQ and put all communication to an external thread and Smalltalk can fly again. That's the difference.
Marten
Am 07.10.2014 um 20:12 schrieb Alain Rastoul:
Thanks you for your answers.
0mq looks great, but released with LGPL licence, and I don't like that (I don't understand why there is also a GPL licence file in the distribution ? - clearly a *noway*), I prefer a full smalltalk implementation I can debug when things go wrong. I think latency and timing problems would be the same, no big difference in performance. BTW knowing about this library is cool and may be of some help (who knows), thank you Marten for the reference.
I agree totally with you Sven about performance and standards. And I also agree with you about reusing someone else's work ... I don't like to reinvent the wheel, especially a good wheel when mine would be worst, I would if I were a wheel specialist - clearly not the case here.
-- Marten Feldtmann