I looking for cross platform multithread message queue implementation on c++ (not slot/signal) . Better if it based on subject-observer pattern.
ZeroMQ looks like it may be what you are looking for.
It is well documented with lots of examples, such as this one: http://www.zeromq.org/blog:multithreaded-server , which may be what you are trying to implement.
Take a look to the "ISL" open source project (stands for an "Internet Server Library", C++), which SVN-repository is located on http://svn.storozhilov.com/isl/ - isl::AbstractMessageBroker class is a good candidate for a basement of your job. This is quite simple but extensible skeleton for any message broker subsystem (DBus, JMS, AMQP, etc.). Each client is served by 2 threads from the pre-started thread's pool: one is for receiving message from the transport and processing message and another is for sending message to transport. So, actually in order to implement your messaging system you have to override at least following three virtual methods:
isl::AbstractMessageBroker::receiveMessage(...);
isl::AbstractMessageBroker::processMessage(...);
isl::AbstractMessageBroker::sendMessage(...);
Example of use is in trunk/examples/EchoMessageBroker directory. Responses client with echoed message, terminates connection on "bye\r\n" message, terminates itself on SIGINT.
You can try out Apache ActiveMQ. http://activemq.apache.org. Quite robust.We use it for a FIX messaging platform, quite responsive and easy to configure also.
Have a look at Intel's Open Source lib Threading Building Blocks. They are cross-platform and last time I looked they had lock-free containers.
Related
Looking to implement an an event based system for a project across multiple linux processes. Essentially, I want to be able to log an event and then notify multiple processes about the event (and also log via rsyslog). I have done this in the past with domain sockets and some custom code, but does anyone know of a better way utilizing Boost or a similar library?
Even better would be a subscription based model where only certain processes would receive certain events.
You have lots of options:
ZeroMQ.
It is high-speed, asynchronous library and contains lots of messaging patterns you can use, e.g. PUB-SUB
C++ Actor Framework -- C++11 actor model implementation
Dataflow.Signals and Boost.Asio -- in case you want to stick to BOOST-based solution. An example can be found here
I am designing a C++ app which consists of largely independent plugins or modules which produce from time to time results useful for other plugins. For example, analysis module comes across some useful piece of data and sends it to action modules. Each module will run in its own thread; this is so analysis modules can continue gathering data while action modules handle the data at the rate they can.
I am looking for a suitable message passing architecture/design pattern. This stackoverflow thread gives some suggestions, but I'm not sure a plain interface will work in multi-threaded environment.
I was thinking of having some sort of channel based architecture, where each module broadcasts something on the channel and whichever module is interested in it - listens to. If there are some ready made libraries under liberal licence - the better.
I've been using ACE (Adaptive Communication Environment) for thread management, TCP/UDP communications, mutex relationships and programming.
ACE is a highly portable collection of invocations of platform core patterns. Best of all, it's free, open source, and currently under active development.
http://www.cs.wustl.edu/~schmidt/ACE.html
For your application, I would recommend looking specifically at class "ACE_Task_Base" to provide multi-threading, and "ACE_Reactor" to register all the handlers for your asynchronous callback architecture.
You might be interested to take a look at ZeroMQ library that acts like a concurrency framework also. Using this library your components would communicate with each other by sending messages to named ZeroMQ sockets. There are many sockets types (TCP, IPC, inproc) and several patterns available for request-reply and publish-subscribe messaging.
How does ZeroC ICE compare to 0MQ? I know that 0MQ/Crossroads and DDS are very similar, but cant seem to figure out where ICE comes in.
I need to quickly implement a system that offloads real-time market-data from C++ to C#, as a first phase of my project. The next phase will be to implement an Event Based architecture with an underlying Pub/Sub design.
I am willing to use TCP.. but the the system is currently running on a single 24 core server.. so an IPC option would be nice. From what I understand ICE is only TCP, while DDS and 0mq have an IPC option.
Currently ,I am leaning towards using Protobuf with either ICE or Crossroads IO. Got turned off from the OpenSplice DDS website. Ive done lots research on the various options, was originally considering OpenMPI + boost:mpi, but there does not seem to be MPI for .NET.
My question is:
How does ICE compare to 0MQ? I cant wrap my head around this. Was unable to find anything online that compares the two.
thanks in advance.
........
More about my project:
Currently using CMAKE C++ on Windows, but the plan is to move to CentOS at some point. An additional desired feature is to store the tic data and all the messages in a "NoSql" database such as Hbase/Hadoop or HDF5. Do any of these middleware/messaging/pub-sub libraries have any database integration?
Some thoughts about ZeroC:
Very fast; Able to have multiple endpoints; Able to load balance on the endpoints; Able to reconnect to a different endpoint in case one of the node goes down. This is transparent to the end user; Has good tool chain (IceGrid, IceStorm, IceBox, etc); Distributed, high availability, multiple failover, etc
Apart from that, I have used it for hot swapping code modules (something similar to Erlang) by having the client create the proxy with multiple endpoints, and later on bring down each endpoint for a quick upgrade one by one. With the transparent retry to a different endpoint, I could have the system up and running the whole time i did an upgrade. Not sure if this is an advertised feature or an unadvertised side-effect :)
Overall, it is very easy to scale out your servers if need be using ZeroC Ice.
I know ZeroMQ provides a fantastic set of tools and messaging patterns and I would keep using it for my pet projects. However, The problem that i see is that it is very easy to go overboard and lose track of all your distributed components. This is a must have in a distributed environment. How will you know where your clients/server are when you need to upgrade? If one of components down the chain does not receive a message, how to identify where the issue is? the publisher? the client? or any one of the bridges (REP/REQ, XREP/XREQ, etc) in between?
Overall, ZeroC provides a much better toolset and ecosystem for enterprise solutions.
And it is open source :)
Jaybny,
ZMQ:
If you want real good performance and the only job for Phase 1 of your job is to move data from C++ to C#, then Zmq is the best option.
Having a pub/sub model for event driven architecture is also something that Zmq can help you with, with its in-built messaging pattern.
Zmq also supports your IPC requirements in this case. Eg: you can have one instance of your application that consumes 24 cores by multithreading and communicating via IPC.
ZeroC Ice:
Ice is a RPC framework very much like CORBA.
Eg.
Socket/ZMQ - You send message over the wire. Read it at the other end, parse the message, do some action, etc.
ZeroC Ice - Create a contract between client and server. Contract is nothing but a template of a class. Now the client calls a proxy method of that class, and the server implements/actions it and returns the value. Thus, int result = mathClass.Add(10,20) is what the client calls. The method, parameters, etc is marshalled and sent to the server, server implements the Add method, returns the result, and the client gets 30 as the result. Thus on the client side, the api is nothing but a proxy for a servant running on a remote host.
Conclusion:
ZeroC ICE has some nice enterprisy features which are really good. However, for your project requirements, ZMQ is the right tool.
Hope this helps.
For me.. the correct answer was Crossroads I/O . It does everything I need.. but still unable to pub/sub when using protobufs... im sure ZeroC ICE is great for distributed IPC, but 0MQ/Crossroads, gives you the added flexibility to use Inter-Thread-Communication.
Note: on windows, 0mq does not have IPC.
So, all in all, the crossroads fork of 0mq is the best. but you will have to roll your own windows/ipc (or use tcp::127..) , and publisher side topic filtering features for pub/sub.
nanomsg, from the guy who wrote crossroads and 0mq (i think).
http://nanomsg.org/
I am implementing a messaging system using C++ and Qt. After much thought, I have determined that multicasting or a multicast-style technique will work best to solve my problem. However, I have learned about UDP's unreliability and believe it to be unacceptable.
My requirements are as follows:
Messages are to be sent in a binary serialized form.
From any given node on the network, I must be able to send messages to the other nodes.
Message delivery must be insured.
I have heard of OpenPGM and NORM as alternatives for UDP. If anyone has experience with either of these, could you please share?
I am also open to the possibility of implementing "reliable" multicast by myself, in the application layer, but I would prefer not to if there is a library that already implements this.
I am using C++ and Qt, therefore .NET or Java-based solutions are not acceptable unless they are open-source and I may port them to C++.
Thank you very much.
EDIT 20120816T1853 MDT: An additional question: would either PGM or NORM have to be implemented at the hardware/IP level? Or can they be overlayed on top of existing protocols?
We have implemented our own reliable multicast protocol over UDP called RSP, since we needed something cross-platform and at the time couldn't find a good solution between Linux and Windows. The Windows PGM implementation disconnects slow clients which leave the send window, whereas our implementation throttles the sender similar to TCP. Afaik OpenPGM can be configured to do the same.
The open source NORM at http://cs.itd.nrl.navy.mil/work/norm can be built as a library and has C++ API with Python and Java language bindings. If you ping the developer (me) via the mailing list, I can help get you started.
There is a large RFC division of reliable multicast protocols, and many implementations out there. It's a long time since I looked at this but there are TRAM, LRMP, ...
I am penning down the features that a remote logging
library might need when built from scratch.
I looked up this: http://www.aggsoft.com/serial-data-logger.htm
I wish to know that what differences can be between a
remote logging library and a remote logger software.
Few things that I thought of:
1. The library can be used in C++ programs to log error messages on the fly.
2. The library will require programming knowledge on the end user's part.
3. The software cannot be used "inside" a C++ program, so we won't be able to log the error messages on the fly? Not sure about this one.
I would like to know that besides logging error messages, what are the things for which it makes sense to use the remote logging library? Sharing big files? Anything else than these two things?
Secondly which is better in what way out of a library and a software - in the current case?
As I mentioned in the my comments to your question, I would think that a logging library would provide some sort of an API/SDK, whereas remote software would not. The same would hold true if its sending messages via TCP/UDP or a serial port. The difference between the 2 options would be how much coding you would have to do. That is, how much would you have to reinvent the wheel?
IMHO, nearly all debug environment/tools support redirect the console output the serial port (using print, or other API). It usually not a a task of Application programmer.
There are other methods for "remote logging":
1) syslog, syslog-ng 's remote service
2) save log local, fetch using ftp