2

I'm going to work on a client/server application in C++ running on Windows, the server being itself made of a "manager" executable, spawned once, and a "worker" executable spawned from 1 to 29 times depending on the configuration.

The coms are between the clients and the "manager" process, between the "manager" process and the "worker" processes (to configure them, send them data to process) and between some of the "worker" processes. On a side note: when I say worker process, I don't mean processes doing exactly the same job in parallel for super performances: they are all configured differently, do a different job, and performance really isn't an issue. The separation in several processes here is more about stability.

Now I don't know what network library to choose to do all that.

I know boost::asio, I am familiar with boost and its particular style, but I'm afraid other members of my team are not. I was also advised to use zeroMq. And I've seen a few others with their pros and cons. But I'm a bit lost!

With zeroMq I think we loose the proactor of asio? So in a sense it feels it is lower level? On the other hand it provides features like publish/subscribe that I don't think are useful for us.

None of those libraries are going to help us with the serialization part (data exchanged is heterogenous). I was thinking google protocol buffer could help us on this point, unless there is a do it all library around?

Other choices we've vaguely considered are Corba, amqp. The former feels clumsy and we've been advised against it. The later feels overly complex. (?)

Any word of advise?

foke
  • 1,339
  • 2
  • 12
  • 20
  • While I don't have any positive recommendations (I've always used my own networking library), I can tell you what to avoid: Definitely avoid CORBA, and avoid ACE too, it's just awful. :) –  Mar 07 '13 at 11:33
  • have you considered gsoap ? Its one of the widely used for soap based architecture – Pradheep Mar 07 '13 at 11:41
  • @James thanks for the input, I forgot to mention ACE. I did use it a bit in the past and wasn't really considering it here. – foke Mar 07 '13 at 12:36
  • 1
    What are the other members on your team familiar with? If they are all going to have to learn something new then at least you are personally familiar with asio already. Otherwise all members of the team are on new ground. – Pete Mar 07 '13 at 12:59
  • You could maybe even write a library that is a layer on top of boost that everyone can use. – Pete Mar 07 '13 at 13:00

2 Answers2

3

ZeroMQ works just fine integrated with Boost.Asio if you chose to go that route. That said, I'd suggest you implement your client and server using Boost.Asio if that's what you're familiar with. It's a fantastically written library, well documented, and has an active user community (that's us) if you have questions.

In my experience most developers who tend to shy away from Asio are unfamiliar with non-blocking I/O and prefer to silo their designs with the thread-per-connection methodology that does not scale beyond trivial examples. Point your colleagues at the Asio examples, send them to StackOverflow so they can read questions in the tag. If they're still not convinced, maybe show them the TR2 networking library proposal based on Asio, it might end up in a standard someday.

Community
  • 1
  • 1
Sam Miller
  • 23,808
  • 4
  • 67
  • 87
  • Well said! Boost.Asio provides a clean and well documented C++ toolkit that can integrate with various middlewares. It would be hard for me to pass up, even if I was only using it as an abstraction to an underlying middleware. – Tanner Sansbury Mar 12 '13 at 04:57
0

with ZMQ, you will probably WANT to use the Publish/Subscribe model (especially efficient in zmq 3.x in comparison to zmq 2.2, since 3.x does published based subscription filtering while 2.2 does client based filtering).

All of the workers would connect to the manager using a SUB socket (doesn't matter what type of worker they are) and Subscribe to the messages that it needs to deal with. The manager would bind a Pub socket and push out all messages that it receives from clients. The workers will only receive messages that it subscribed to. This is very efficient and in all honesty the way I would implement this behavior.

If you have multiple workers that DO work on the same messages (for performance), you'd want to create an intermediate 'worker' that subscribes to that specific message type and binds a PUSH socket where workers of the same type will connect to that intermediate 'worker' (also called a router) with PULL sockets. That way the incoming messages will be 'queued' up and fanned out as the workers each finish a task.

I would probably create that intermediate step right from the get-go so that you can scale out of the box without too much issue (if it were ever really needed).

g19fanatic
  • 10,567
  • 6
  • 33
  • 63