13

I'm developing a new client-server app (.Net) and have up until now been using WCF, which suits the app's request-response approach nicely. However I've been asked to replace this with a socket-based solution, partly to support non-.Net clients, and future pub-sub/broadcast requirements (I realise WCF is capable, but there are other drivers behind the decision). Having failed miserably at writing my own async socket solution, I'm now looking at ZeroMQ.

My client app has a couple of background threads that periodically request data from the server. Additionally, certain UI actions (e.g. a button click) can trigger a message to the server. WCF made this easy - the code simply called the relevant method on a singleton WCF service proxy (actually I use the Castle Windsor WCF facility which gives me async calling capabilities, but that's probably irrelevant to my question).

I'm not too sure how this approach would translate to ZeroMQ, particularly with regards to managing the sockets - I'm very new to ZeroMQ and still reading the guide. Am I right in saying that I'll need a separate socket for each thread (i.e. the two b/g threads and the UI)? What about socket lifetime - do I create one each time I want to send/receive (presumably inefficient), or create the socket when the thread starts and reuse it for the entire lifetime of the thread?

Andrew Stephens
  • 9,413
  • 6
  • 76
  • 152

2 Answers2

16

One thing has to be very clear. ZMQ sockets can connect and talk to ZMQ sockets only.

This means that if I am building an distributed application whose components communicate to each other, I have liberty to choose any communication approach as external clients are not exposed to it.

Choosing ZMQ Sockets for such means is a good idea. It allows you to instantly build on many communication patterns like req/rep, push/pull, pub/sub etc and also build more complicated topologies using ZMQ devices.

How ever, This constraint is not to be taken lightly when external clients are concerned. This will enforce all external clients to use ZMQ sockets which might not be ideal. If one of the client happens to be a browser consuming your web services then you will need to provide services through regular client.

Is your client app using regular sockets? Can it be re-written to use ZMQ sockets?

if not then don't use ZMQ sockets for external interface but only for your internal component communication.

[Edit: Further notes]

ZMQ is a wrapper over sockets but that does a few things which are hard to get done by hand

  1. It manages messaging at higher throughput by batching multiple messages at the same time
  2. Optimizes use of socket at the same time
  3. A socket can send messages to only one another socket, ZMQ socket can connect to multiple ZMQ sockets
  4. ZMQ socket based solution can take immediate advantage of various patterns - REQ/REP, PUSH/PULL, PUB/SUB etc

How ever, it is common to mistake ZMQ to be a messaging queue.

  1. Messaging Queue as available has other properties like message persistence and delivery guarantee etc by implementing a queue for storage.
  2. ZMQ stands for "Zero Messaging Queue"

I have only been learning ZMQ in recent times and have been very happy to use it.

Checkout my mini tutorial on ZMQ and See if it make sense for you to use it:

http://learning-0mq-with-pyzmq.readthedocs.org/en/latest/

pyfunc
  • 65,343
  • 15
  • 148
  • 136
  • 1
    It's primarily a .Net client and server, but there may be Python clients in the future (that's ok as there is a Python ZMQ library). It's also feasible that in the future we may want web/smartphone/iPad etc clients, which I guess ZMQ wouldn't be suitable for. – Andrew Stephens Jun 26 '12 at 12:59
  • 2
    To me ZMQ feels like a glorified wrapper around sockets. I'm finding I have to write an awful lot of code to get something to work. If my clients send messages to the server too quickly, they get discarded. I've had to write code (similar to the ZMQ async client-server sample) to employ multiple worker threads in the server to ensure the incoming messages are handled quickly. Surely the point of a MQ is that is employs a queuing mechanism to stop messages getting lost?! It seems to be lacking much of what you'd get out of the box in other MQs, and I'm finding it a bit frustrating. – Andrew Stephens Jun 26 '12 at 13:09
  • 4
    For anyone who finds this answer: "ZMQ sockets can connect to ZMQ sockets only" is not true any more. See [here](http://stackoverflow.com/q/17176871/548513) or [here](http://comments.gmane.org/gmane.network.zeromq.devel/19547). ZMQ 4.x can connect with TCP sockets, too. – Robin Feb 10 '16 at 14:26
1

Regarding castle integration, check out what Henry's done on his fork:

https://github.com/hconceicao/clrzmq2/tree/master/src/integration

hammett
  • 705
  • 4
  • 13