Bolt (network protocol)

Last updated

Bolt
Original author(s) Neo Technology
Stable release
Version 1
Written inVarious languages
Operating system Any
Platform Cross-platform
Type Network protocol
License Creative Commons 3.0 Attribution-ShareAlike
Website boltprotocol.org

The Bolt Protocol (Bolt) is a connection oriented network protocol used for client-server communication in database applications. It operates over a TCP connection or WebSocket.

Contents

Bolt is statement-oriented, allowing a client to send messages containing a statement consisting of a single string and a set of typed parameters. The server responds to each statement with a result message and an optional stream of result records.

History

The Bolt protocol was first introduced to the public in November 2015, during an interview conducted by Duncan Brown and published on DZone. [1] The first release of software implementing the protocol occurred in December 2015, as part of a milestone release of Neo4j Server. [2] In April 2016, Neo4j Server 3.0 was released and contained the first server implementation of the protocol, accompanied by a suite of Bolt client drivers. This release received attention from several mainstream media outlets. [3] [4] [5]

Versioning

The protocol supports explicit versioning and version negotiation between the client and the server. There is only one published version of the protocol: version 1.

Protocol overview - version 1

Messaging

A typical interaction in the Bolt network protocol Bolt-typical-interaction.png
A typical interaction in the Bolt network protocol

Bolt clients and servers both send data over the connection as a sequence of messages. Each message has a type (denoted by a "signature" byte) and may include additional data. The client drives the interaction, and each message sent by the client will cause one or more response messages to be sent by the server.

Client messages:

TypeSignature
INIT0x01 [6]
RUN0x10 [7]
DISCARD_ALL0x2F [8]
PULL_ALL0x3F [9]
ACK_FAILURE0x0E [10]
RESET0x0F [11]

Server messages:

TypeSignature
SUCCESS0x70 [12]
FAILURE0x7F [13]
IGNORED0x7E [14]
RECORD0x71 [15]

Message transfer encoding

Each message is encoded into a sequence of bytes. These bytes are transferred using a binary chunked encoding, where each chunk is preceded by an unsigned, big-endian 16-bit integer denoting the number of bytes that immediately follow. A length of 0 is used to denote the end of the message.

Failure handling

A client may send multiple messages to a server, without first waiting for a response. [16] The server processes each message sequentially. However, as there may be logical dependencies between messages sent by the client, the server will not evaluate requests it receives after sending FAILURE in response to a preceding message. Instead, it will send an IGNORED message in reply to every client message, until the client acknowledges the failure by sending an ACK_FAILURE message.

This is similar to the failure handling and recovery in the PostgreSQL wire protocol.

Data encoding

Bolt supports encoding for a number of different data types.

TypeDescription
Null [17] Represents the absence of a value.
Boolean [18] Boolean true or false.
Integer [19] 64-bit signed integer.
Float [20] 64-bit floating point number.
String [21] UTF-8 encoded string.
List [22] Ordered collection of values.
Map [23] Unordered, keyed collection of values.
Node [24] A node in a Property Graph with optional properties and labels.
Relationship [25] A directed, typed connection between two nodes in a Property Graph. Each relationship may have properties and always has an identity.
Path [26] The record of a directed walk through a Property Graph, consisting of a sequence of zero or more segments.

Related Research Articles

The Dynamic Host Configuration Protocol (DHCP) is a network management protocol used on Internet Protocol (IP) networks for automatically assigning IP addresses and other communication parameters to devices connected to the network using a client–server architecture.

<span class="mw-page-title-main">Hypertext Transfer Protocol</span> Application protocol for distributed, collaborative, hypermedia information systems

The Hypertext Transfer Protocol (HTTP) is an application layer protocol in the Internet protocol suite model for distributed, collaborative, hypermedia information systems. HTTP is the foundation of data communication for the World Wide Web, where hypertext documents include hyperlinks to other resources that the user can easily access, for example by a mouse click or by tapping the screen in a web browser.

Multipurpose Internet Mail Extensions (MIME) is an Internet standard that extends the format of email messages to support text in character sets other than ASCII, as well as attachments of audio, video, images, and application programs. Message bodies may consist of multiple parts, and header information may be specified in non-ASCII character sets. Email messages with MIME formatting are typically transmitted with standard protocols, such as the Simple Mail Transfer Protocol (SMTP), the Post Office Protocol (POP), and the Internet Message Access Protocol (IMAP).

The Simple Mail Transfer Protocol (SMTP) is an Internet standard communication protocol for electronic mail transmission. Mail servers and other message transfer agents use SMTP to send and receive mail messages. User-level email clients typically use SMTP only for sending messages to a mail server for relaying, and typically submit outgoing email to the mail server on port 587 or 465 per RFC 8314. For retrieving messages, IMAP is standard, but proprietary servers also often implement proprietary protocols, e.g., Exchange ActiveSync.

Short Message Peer-to-Peer (SMPP) in the telecommunications industry is an open, industry standard protocol designed to provide a flexible data communication interface for the transfer of short message data between External Short Messaging Entities (ESMEs), Routing Entities (REs) and SMSC.

The File Transfer Protocol (FTP) is a standard communication protocol used for the transfer of computer files from a server to a client on a computer network. FTP is built on a client–server model architecture using separate control and data connections between the client and the server. FTP users may authenticate themselves with a clear-text sign-in protocol, normally in the form of a username and password, but can connect anonymously if the server is configured to allow it. For secure transmission that protects the username and password, and encrypts the content, FTP is often secured with SSL/TLS (FTPS) or replaced with SSH File Transfer Protocol (SFTP).

Transport Layer Security (TLS) is a cryptographic protocol designed to provide communications security over a computer network. The protocol is widely used in applications such as email, instant messaging, and voice over IP, but its use in securing HTTPS remains the most publicly visible.

UTF-7 is an obsolete variable-length character encoding for representing Unicode text using a stream of ASCII characters. It was originally intended to provide a means of encoding Unicode text for use in Internet E-mail messages that was more efficient than the combination of UTF-8 with quoted-printable.

Modbus is a data communications protocol originally published by Modicon in 1979 for use with its programmable logic controllers (PLCs). Modbus has become a de facto standard communication protocol and is now a commonly available means of connecting industrial electronic devices.

Real-Time Messaging Protocol (RTMP) is a communication protocol for streaming audio, video, and data over the Internet. Originally developed as a proprietary protocol by Macromedia for streaming between Flash Player and the Flash Communication Server, Adobe has released an incomplete version of the specification of the protocol for public use.

Within communication protocols, TLV is an encoding scheme used for optional informational elements in a certain protocol. A TLV-encoded data stream contains code related to the record type, the record value's length, and finally the value itself.

Chunked transfer encoding is a streaming data transfer mechanism available in Hypertext Transfer Protocol (HTTP) version 1.1, defined in RFC 9112 §7.1. In chunked transfer encoding, the data stream is divided into a series of non-overlapping "chunks". The chunks are sent out and received independently of one another. No knowledge of the data stream outside the currently-being-processed chunk is necessary for both the sender and the receiver at any given time.

<span class="mw-page-title-main">HTTP persistent connection</span> Using a single TCP connection to send and receive multiple HTTP requests/responses

HTTP persistent connection, also called HTTP keep-alive, or HTTP connection reuse, is the idea of using a single TCP connection to send and receive multiple HTTP requests/responses, as opposed to opening a new connection for every single request/response pair. The newer HTTP/2 protocol uses the same idea and takes it further to allow multiple concurrent requests/responses to be multiplexed over a single connection.

Action Message Format (AMF) is a binary format used to serialize object graphs such as ActionScript objects and XML, or send messages between an Adobe Flash client and a remote service, usually a Flash Media Server or third party alternatives. The Actionscript 3 language provides classes for encoding and decoding from the AMF format.

<span class="mw-page-title-main">Byte serving</span> HTTP facility to fetch a specific part of a file

Byte serving is the process introduced in HTTP protocol 1.1 of sending only a portion of a message from a server to a client. Byte serving begins when an HTTP server advertises its willingness to serve partial requests using the Accept-Ranges response header. A client then requests a specific part of a file from the server using the Range request header. If the range is valid, the server sends it to the client with a 206 Partial Content status code and a Content-Range header listing the range sent. If the range is invalid, the server responds with a 416 Requested Range Not Satisfiable status code.

<span class="mw-page-title-main">Key Management Interoperability Protocol</span>

The Key Management Interoperability Protocol (KMIP) is an extensible communication protocol that defines message formats for the manipulation of cryptographic keys on a key management server. This facilitates data encryption by simplifying encryption key management. Keys may be created on a server and then retrieved, possibly wrapped by other keys. Both symmetric and asymmetric keys are supported, including the ability to sign certificates. KMIP also allows for clients to ask a server to encrypt or decrypt data, without needing direct access to the key.

In the BitTorrent file distribution system, a torrent file or meta-info file is a computer file that contains metadata about files and folders to be distributed, and usually also a list of the network locations of trackers, which are computers that help participants in the system find each other and form efficient distribution groups called swarms. A torrent file does not contain the content to be distributed; it only contains information about those files, such as their names, folder structure, sizes, and cryptographic hash values for verifying file integrity. The term torrent may refer either to the metadata file or to the files downloaded, depending on the context.

<span class="mw-page-title-main">WebSocket</span> Computer network protocol

WebSocket is a computer communications protocol, providing full-duplex communication channels over a single TCP connection. The WebSocket protocol was standardized by the IETF as RFC 6455 in 2011. The current API specification allowing web applications to use this protocol is known as WebSockets. It is a living standard maintained by the WHATWG and a successor to The WebSocket API from the W3C.

An rpmsg file is a restricted-permission message with an extension of rpmsg. It is used to implement IRM for Outlook messages with the aim of controlling access to content via encryption and access controls, and restricting certain actions such as the ability to forward or copy.

The Stream Control Transmission Protocol (SCTP) is a computer networking communications protocol in the transport layer of the Internet protocol suite. Originally intended for Signaling System 7 (SS7) message transport in telecommunication, the protocol provides the message-oriented feature of the User Datagram Protocol (UDP), while ensuring reliable, in-sequence transport of messages with congestion control like the Transmission Control Protocol (TCP). Unlike UDP and TCP, the protocol supports multihoming and redundant paths to increase resilience and reliability.

References

  1. "Introducing Bolt, Neo4j's Upcoming Binary Protocol – Part 1 - DZone Database". dzone.com. Retrieved June 2, 2017.
  2. "Bolting Forward: The Neo4j 3.0 Milestone 1 Release Is Here - Neo4j Graph Database". neo4j.com. December 4, 2015. Retrieved June 2, 2017.
  3. Martin, Alexander J. (April 26, 2016). "Neo4j bolts on binary protocol to up its graph database game". theregister.co.uk. Retrieved June 2, 2017.
  4. "Neo4j 3.0 Released with Binary Communication Protocol and Standardised Drivers". InfoQ. Retrieved June 2, 2017.
  5. "Neo Technology Releases Neo4j 3.0". tomsitpro.com. April 26, 2016. Archived from the original on May 7, 2017. Retrieved June 2, 2017.
  6. "Bolt Protocol, Version 1". boltprotocol.org. Retrieved June 2, 2017.
  7. "Bolt Protocol, Version 1". boltprotocol.org. Retrieved June 2, 2017.
  8. "Bolt Protocol, Version 1". boltprotocol.org. Retrieved June 2, 2017.
  9. "Bolt Protocol, Version 1". boltprotocol.org. Retrieved June 2, 2017.
  10. "Bolt Protocol, Version 1". boltprotocol.org. Retrieved June 2, 2017.
  11. "Bolt Protocol, Version 1". boltprotocol.org. Retrieved June 2, 2017.
  12. "Bolt Protocol, Version 1". boltprotocol.org. Retrieved June 2, 2017.
  13. "Bolt Protocol, Version 1". boltprotocol.org. Retrieved June 2, 2017.
  14. "Bolt Protocol, Version 1". boltprotocol.org. Retrieved June 2, 2017.
  15. "Bolt Protocol, Version 1". boltprotocol.org. Retrieved June 2, 2017.
  16. "Bolt Protocol, Version 1". boltprotocol.org. Retrieved June 2, 2017.
  17. "Bolt Protocol, Version 1". boltprotocol.org. Retrieved June 2, 2017.
  18. "Bolt Protocol, Version 1". boltprotocol.org. Retrieved June 2, 2017.
  19. "Bolt Protocol, Version 1". boltprotocol.org. Retrieved June 2, 2017.
  20. "Bolt Protocol, Version 1". boltprotocol.org. Retrieved June 2, 2017.
  21. "Bolt Protocol, Version 1". boltprotocol.org. Retrieved June 2, 2017.
  22. "Bolt Protocol, Version 1". boltprotocol.org. Retrieved June 2, 2017.
  23. "Bolt Protocol, Version 1". boltprotocol.org. Retrieved June 2, 2017.
  24. "Bolt Protocol, Version 1". boltprotocol.org. Retrieved June 2, 2017.
  25. "Bolt Protocol, Version 1". boltprotocol.org. Retrieved June 2, 2017.
  26. "Bolt Protocol, Version 1". boltprotocol.org. Retrieved June 2, 2017.