What's better for Video and Real-Time Control - ZMQ or Websockets?

Question

I am writing a remote server to control a robot with. The robot provides video and its current sensor state; the server sends control commands.

My choices for sending the frames and the control/sensor-state between the robot and the server ( 2-way ) are ZeroMQ and WebSockets.

I need:

1. Speed
2. Security

My coding partner wants to use Websockets because it's undergoing standardization, but I have 3 months of experience using ZMQ to do just what we're trying to do, so I'm fairly certain the choice doesn't matter.

However, I'd like to know if anyone can think of a compelling reason to go with one OR the other (XOR). We're not going to use ZMQ+Websockets because we don't need to.

Answer 1

Looking at what WebSockets are, I honestly don't think it's going to make much difference. They're simply a way to switch between speaking HTTP to the WebSocket framed message protocol down the same TCP connection. ZMQ gives you framed messages too, but you'd be using that over a network connection separate from the web browser's HTTP connection.

Latency comparisons are going to depend on just how good a run time environment the Web Browser provides. It seems to me that use of WebSockets will involve writing the client side code in Javascript and running that in the browser (the "modern" way), so that code will be at the mercy of the Web browser's Javascript engine (they're pretty good I think).

With ZMQ you may be having to write a native application for the client end (I don't know if it can be used within a web browser within Javascript - I need some education!). A native application is free of any influence from a web browser, so it might be just a shade better.

But if your real time requirement is only on the human scale (i.e. it need respond only quick enough to make a human happy), I think either will likely be sufficient. Neither can overcome propagation times across the Internet, neither can account for OS / browser delays.

The one difference is that with WebSockets it looks like you have to switch between HTTP and WebSocket protocol. So if you need to switch back to HTTP to load some web element or other, that's going to interrupt the flow of WebSocket data until you switch back again. Whether or not that is actually a problem is going to depend very much on what your client side application is doing (for example, you may very well be talking to a separate web server for web page elements, in which case you'd have two connections on the go anyway).

With ZMQ you're going to have a dedicated connection.