Differences between ZeroMQ and WebSockets

websocket zeromq low-latency nanomsg

repalviglator · Oct 31, 2014 · Viewed 14.1k times · Source

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.

Answer

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 ).

_{In case one has never worked with ZeroMQ,
one may here enjoy to first look at "ZeroMQ Principles in less than Five Seconds"
before diving into further details}

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.

enter image description here

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.