ArangoDB | VelocyStream Async Binary Protocol – Data Streaming

With the 3.2 release, ArangoDB comes with version 1.1 of the binary protocol VelocyStream. VelocyStream is a bi-directional async binary protocol which supports sending messages pipelined, multiplexed, uni-directional or bi-directional. The messages themselves are VelocyPack objects.

The story of VelocyStream began with version 3.0 of ArangoDB which introduced VelocyPack as the new internal storage format of ArangoDB. VelocyPack as a binary format – which stores a superset of JSON, is more compact and has a fast attribute lookup – allows us to use the same byte sequence of data for storage, read-only work and last but not least transport. Next to the already existing advantages in 3.0, like reducing runtime memory and data conversions, we have created all conditions to implement a protocol to transport our storage format in an optimized form directly between ArangoDB and client applications.

With 3.1 the first version of VelocyStream found their way into ArangoDB. Contemporaneous an overhaul version of the official Java driver was released which used VelocyStream as transport protocol. With this release, we were able to show that our vision of VelocyStream is heading in the right direction and that we are already able to see performance gains with it. In addition, a second Java driver was built to provide an API for asynchronous operations which were possible due to the async characteristic of VelocyStream.

Facing the 3.2 release we gave VelocyStream further improvements with version 1.1 and published the specification so that developers of third party drivers can implement it too. Also, we released our C++ driver and Go driver with VelocyStream support and an updated JavaScript driver is also on its way.

How does it work?

To understand how VelocyStream achieves the benefits over HTTP let’s take a look at its structure. VelocyStream messages consist of one or more VelocyPacks. Each message has a unique id and is split into one or more chunks depending on the size of the message. These chunks are sent one after another over one connection, such that other chunks from other requests can appear between chunks. Thus, short requests can overtake long ones on a single connection, and the answer to a later request can be sent before all previous requests have been answered. Different to HTTP this prevents time intensive operations on the server from blocking the whole communication with the client.

One additional advantage of VelocyStream is the reduced overhead when it comes to authentication. Unlike HTTP – where every request needs to deliver the user credentials – VelocyStream only has to authenticate the connection after opening it. A specific message – including the user credentials – has to be sent. Every following message doesn’t have to provide any further information.

On the downside, VelocyStream does not work together with an HTTP proxy but as an alternative since version 3.1, ArangoDB supports to communicate over HTTP with VelocyPack as content. This won’t let you use all the benefits from VelocyStream but nevertheless gives you the advantage of decaying data conversions in the transport layer.