Binary protocol

EdgeDB uses a message-based binary protocol for communication between clients and servers. The protocol is supported over TCP/IP.

Conventions and data Types

The message format descriptions in this section use a C-like struct definitions to describe their layout. The structs are packed, i.e. there are never any alignment gaps.

The following data types are used in the descriptions:

int8

8-bit integer

int16

16-bit integer, most significant byte first

int32

32-bit integer, most significant byte first

int64

64-bit integer, most significant byte first

uint8

8-bit unsigned integer

uint16

16-bit unsigned integer, most significant byte first

uint32

32-bit unsigned integer, most significant byte first

uint64

64-bit unsigned integer, most significant byte first

int8<T> or uint8<T>

an 8-bit signed or unsigned integer enumeration, where T denotes the name of the enumeration

string

a UTF-8 encoded text string prefixed with its byte length as uint32

bytes

a byte string prefixed with its length as uint32

KeyValue

Binary protocol - 图1Copy
  1. struct KeyValue {
  2.   // Key code (specific to the type of the
  3.   // Message).
  4.   uint16          code;
  6.   // Value data.
  7.   bytes           value;
  8. };

Annotation

Binary protocol - 图2Copy
  1. struct Annotation {
  2.   // Name of the annotation
  3.   string          name;
  5.   // Value of the annotation (in JSON
  6.   // format).
  7.   string          value;
  8. };

uuid

an array of 16 bytes with no length prefix, equivalent to byte[16]

Message Format

All messages in the EdgeDB wire protocol have the following format:

  1. struct {
  2.     uint8    message_type;
  3.     int32    payload_length;
  4.     uint8    payload[payload_length - 4];
  5. };

The server and the client MUST not fragment messages. I.e the complete message must be sent before starting a new message. It’s advised that whole message should be buffered before initiating a network call (but this requirement is neither observable nor enforceable at the other side). It’s also common to buffer the whole message on the receiver side before starting to process it.

Errors

At any point the server may send an ErrorResponse indicating an error condition. This is implied in the message flow documentation, and only successful paths are explicitly documented. The handling of the ErrorResponse message depends on the connection phase, as well as the severity of the error.

If the server is not able to recover from an error, the connection is closed immediately after an ErrorResponse message is sent.

Logs

Similarly to ErrorResponse the server may send a LogMessage message. The client should handle the message and continue as before.

Message Flow

There are two main phases in the lifetime of an EdgeDB connection: the connection phase, and the command phase. The connection phase is responsible for negotiating the protocol and connection parameters, including authentication. The command phase is the regular operation phase where the server is processing queries sent by the client.

Connection Phase

To begin a session, a client opens a connection to the server, and sends the ClientHandshake. The server responds in one of three ways:

  1. One of the authentication messages (see below);

  2. ServerHandshake followed by one of the authentication messages;

  3. ErrorResponse which indicates an invalid client handshake message.

ServerHandshake is only sent if the requested connection parameters cannot be fully satisfied; the server responds to offer the protocol parameters it is willing to support. Client may proceed by noting lower protocol version and/or absent extensions. Client MUST close the connection if protocol version is unsupported. Server MUST send subset of the extensions received in ClientHandshake (i.e. it never adds extra ones).

While it’s not required by the protocol specification itself, EdgeDB server currently requires setting the following params in ClientHandshake:

  • user – username for authentication

  • database – database to connect to

Authentication

The server then initiates the authentication cycle by sending an authentication request message, to which the client must respond with an appropriate authentication response message.

The following messages are sent by the server in the authentication cycle:

AuthenticationOK

Authentication is successful.

AuthenticationSASL

The client must now initiate a SASL negotiation, using one of the SASL mechanisms listed in the message. The client will send an AuthenticationSASLInitialResponse with the name of the selected mechanism, and the first part of the SASL data stream in response to this. If further messages are needed, the server will respond with AuthenticationSASLContinue.

AuthenticationSASLContinue

This message contains challenge data from the previous step of SASL negotiation (AuthenticationSASL, or a previous AuthenticationSASLContinue). The client must respond with an AuthenticationSASLResponse message.

AuthenticationSASLFinal

SASL authentication has completed with additional mechanism-specific data for the client. The server will next send AuthenticationOK to indicate successful authentication, or an ErrorResponse to indicate failure. This message is sent only if the SASL mechanism specifies additional data to be sent from server to client at completion.

If the frontend does not support the authentication method requested by the server, then it should immediately close the connection.

Once the server has confirmed successful authentication with AuthenticationOK, it then sends one or more of the following messages:

ServerKeyData

This message provides per-connection secret-key data that the client must save if it wants to be able to issue certain requests later. The client should not respond to this message.

ParameterStatus

This message informs the frontend about the setting of certain server parameters. The client can ignore this message, or record the settings for its future use. The client should not respond to this message.

The connection phase ends when the server sends the first ReadyForCommand message, indicating the start of a command cycle.

Command Phase

In the command phase, the server expects the client to send one of the following messages:

Parse

Instructs the server to parse the provided command or commands for execution. The server responds with a CommandDataDescription containing the type descriptor data necessary to perform data I/O for this command.

Execute

Execute the provided command or commands. This message expects the client to declare a correct type descriptor identifier for command arguments. If the declared input type descriptor does not match the expected value, a CommandDataDescription message is returned followed by a ParameterTypeMismatchError in an ErrorResponse message.

If the declared output type descriptor does not match, the server will send a CommandDataDescription prior to sending any Data messages.

The client could attach state data in both messages. When doing so, the client must also set a correct type descriptor identifier for the state data. If the declared state type descriptor does not match the expected value, a StateDataDescription message is returned followed by a StateMismatchError in an ErrorResponse message. However, the special type id of zero 00000000-0000-0000-0000-000000000000 for empty/default state is always a match.

Each of the messages could contain one or more EdgeQL commands separated by a semicolon (;). If more than one EdgeQL command is found in a single message, the server will treat the commands as an EdgeQL script. EdgeQL scripts are always atomic, they will be executed in an implicit transaction block if no explicit transaction is currently active. Therefore, EdgeQL scripts have limitations on the kinds of EdgeQL commands they can contain:

  • Transaction control commands are not allowed, like start transaction, commit, declare savepoint, or rollback to savepoint.

  • Non-transactional commands, like create database or configure instance are not allowed.

In the command phase, the server can be in one of the three main states:

  • idle: server is waiting for a command;

  • busy: server is executing a command;

  • error: server encountered an error and is discarding incoming messages.

Whenever a server switches to the idle state, it sends a ReadyForCommand message.

Whenever a server encounters an error, it sends an ErrorResponse message and switches into the error state.

To switch a server from the error state into the idle state, a Sync message must be sent by the client.

Dump Database Flow

Backup flow goes as following:

  1. Client sends Dump message

  2. Server sends Dump Header message

  3. Server sends one or more Dump Block messages

  4. Server sends CommandComplete message

Usually client should send Sync after Dump message to finish implicit transaction.

Restore Database Flow

Restore procedure fills up the database the client is connected to with the schema and data from the dump file.

Flow is the following:

  1. Client sends Restore message with the dump header block

  2. Server sends RestoreReady message as a confirmation that it has accepted the header, restored schema and ready to receive data blocks

  3. Clients sends one or more RestoreBlock messages

  4. Client sends RestoreEof message

  5. Server sends CommandComplete message

Note: ErrorResponse may be sent from the server at any time. In case of error, Sync must be sent and all subsequent messages ignored until ReadyForCommand is received.

Restore protocol doesn’t require a Sync message except for error cases.

Termination

The normal termination procedure is that the client sends a Terminate message and immediately closes the connection. On receipt of this message, the server cleans up the connection resources and closes the connection.

In some cases the server might disconnect without a client request to do so. In such cases the server will attempt to send an ErrorResponse or a LogMessage message to indicate the reason for the disconnection.