Differences between ZeroMQ and WebSockets

Question

I'd like to know what the differences are between the ZeroMQ and WebSockets protocols. I know WebSockets was designed for web browser clients, but I'm assuming it can also be used server to server. And, in that case, I'm wondering if it would be good to use WebSockets instead of something else like ZeroMQ for real-time messaging. Specifically, I'm worried about reliability and missing messages in case of temporary network failure.

Aubigny

ZeroMQ uses multiple transports (inproc, icp, tcp, pgm, ...) , and now can also use Websocket on the transport layer. So you can send ZMQ messages over websockets. – Blackfish

Answer 1

A: Real-Time-Messaging is a nice tag, however

You may soon realise, that once going into the territory of Real-Time, there is no justification for spending clock-cycles on wrapping any message into the XHTML-Matrjoska-in-Another-Matrjoska-inside-another-Matrjoska alike envelopes-inside-envelopes and associated inefficiencies.

Real-Time struggles to operate in real time, so to spend/lose a minimum achievable time necessary to process a taskUnit.

While there are attempts to re-wrap things in similar *ML-"sexy" manner, the resulting performance is just degraded, going "outside" of the Real-Time territory, instead of any significant help in performing better there.

A very good example of this is a nonsense related to an "quasi-IT-guru-crowd" efforts making financial markets' standard FIX-Protocol "extension" for XHTML-encoded payloads, while the créme-a-la-créme efforts in High-Frequency-Trading R&D spend immense funds/time/efforts on how to shave down nanoseconds associated with each IP-packet wire-unloading & fastest possible de-mapping/de-coding of the awaited real-time data-elements contained there in a minimalistic design of prefixTag:value original specification.

A: Protocol differences are principal

While WebSockets focus on port:80 HTML/XHTML-alike wrapping and framing of some high-level payload-content, ZeroMQ goes right into an opposite direction. It "hides" & "off-loads" the code from any low-level details on transports ( being thus transparently served over INPROC / IPC / TCP / PGM / EPGM / UDP / VMCI / ... transport classes, be it locally, cloud-wide or a mix of both )

The WebSocket protocol has the fixed client and server role and HTTP-style handshaking.

WebSocket focus finishes at UTF-8/CRLF content formatting, framing between a pair of 0×00 & 0xff bytes and builds on WebBrowsers' ability to parse such buffered messages, which the browser were designed to be able to do ).

---

ZeroMQ gives a designer an open architecture to build on building blocks, that were elaborated to cooperate in certain manners -- yes, they have BEHAVIOUR -- that the design is using for some more complex messaging pattern. This allows unlimited upper-layer abstractions, that build on a set of proven building blocks -- ZMQ.PUBLISHER just sends messages to all ZMQ.SUBSCRIBER-s, that listen to and that have demonstrated their respective will to subscribe to some of the news being published. Other ZMQ-primitives help making round-robin based load-balancers, additional steps allow to build fail-safe architectures and similar advanced solutions.

A: Protocol features

While you asked about reliability of a protocol, there are more important attributes at the protocol level -- Assembly/Reassembly/Decomposition overheads, Performance-scaleability, API-to-wire-access latency, thread-safe and relaxation of performance attributes under growing levels of workload.

While WebSocket port:80 communication is "open" to any non-WebSocket intrusion, ZeroMQ low-level protocols were designed for fast, efficient, exclusive ZMQ-2-ZMQ, peer handshaking and all the design efforts are being built from a higher abstraction API level, from which one may add application-based soft-signalling, that may introduce repair/remedy activities so that your requested missing-message issue does not create any adverse effect on the application state.

---

Concurrent systems' programmers

would also like a few advanced bonus points on threading and zero-copy & zero-latency internalities from this piece of in-depth insight from Martin SUSTRIK, a co-father of both ZeroMQ & its younger POSIX-compliant sister nanomsg

Improbity

I didnt understand probably 90% of this answer - but it used big words so, must be good – Flying

I also didn't understand 90% of this answer. Here is the source for that flowchart: zguide.zeromq.org/docs/chapter2/#Missing-Message-Problem-Solver – Dionysius

Answer 2

Your question sounds like "what's the difference between Apache and HTTP"

WebSockets is just a protocol (similar to http), while ZeroMQ is protocol and server which is responsible for lifecycle of your message from the moment it is received until it's consumed.

Kerguelen

You might have already noticed, that ZeroMQ is a Broker-less messaging/signalling framework & the message lifecycle is thus managed in a network of distributed peer-nodes, participating on transport-class specific duties in a decentralised manner. Your answer should not mention a (cit.:) " ... and a server which is responsible ... until it's consumed". This is simply not exact or true for ZeroMQ Scaleable Formal Communication Patterns' framework. An "Apache and HTTP" example of difference betweed apples to oranges was nice, but you might want to revise your other statements. – Improbity

#26683134 refer this – Ozmo

Answer 3

There are some interesting differences.

ZeroMQ is strictly Actor model. Transfers of messages are asynchronous. Where a connection exists between endpoints, ZeroMQ guarantees that whole messages are delivered, or not delivered at all (i.e. no partials). Being Actor model, the possible locations for a messages are 1) in the sending application, 2) somewhere in the transport, or 3) in the receiving application.

It looks like WebSockets are effectively a http operation with some encoding on top. This is probably more akin to Communicating Sequential Processes. CSP is a development of Actor Model, but the act of sending is synchronous with the act of receiving a message. It's an "execution rendezvous". Presumably, with http being used, the "sending" knows for sure that a message has been deposited in the receiving application because the http session completes, and presumably that requires the receiving application to be sat there, ready and waiting, having set up the http server in the first place (caveat - I've never used websockets, and it may be that there's effectively some hidden queing between the http server and the actual server applcation).

The difference with CSP is that there are only 2 places messages can be: 1) in the sending application, or 2) in the receiving application. There's no vague "on the way" location that you get with ZeroMQ.

As ever, it's impossible to say what is best, because it depends on what one's needs are.

CSP is better for strict hard real time applications, because you're not hiding latency of processing messages by bottling up messages in a queue / OS tcp buffer / NIC memory / Ethernet switches. However, CSP is less efficient use of IP networks, because there's more protocol data flowing to and fro across the underlying network to confirm and close the http transfer session. Note that "real time" does not necessarily mean "fast", but it does imply "assured". CSP systems can be mathematically proven correct (Tony Hoare concocted a process calculii for it, indeed the motivation of CSP was to be easily mathematically analysable), and if systemic issues are written into a system they're guaranteed to happen every time (i.e. it's easy to find issues in testing).

Actor Model can make better use of whatever communications resources exist, but cannot be proved correct and can hide nasty issues (like deadlock) until one busy day when the network is a bit slower. ZeroMQ doesn't let you reclaim messages from the queue, and depending on what goes wrong with a network sent messages for some patterns do get discarded (by design). This may or may not be a problem. You cannot prove Actor Model systems to be correct (except in trivial cases), and testing will not necessarily reveal systemic issues such as livelock, deadlock.

Regardless, it's possible to implement a CSP regime in an Actor Model system (one interposes a message ack / nack protocol on top of ZeroMQ), and it's possible to implement an Actor Model regime in CSP (one has an in-application message queue of outbound messages).

Sauternes