Client-server requests and responses

This section describes client requests, their arguments, and the values returned by the server.

Some requests are described on separate pages. Those are the requests related to:

• stream transactions
• asynchronous server-client notifications
• replication
• SQL – IPROTO_EXECUTE and IPROTO_PREPARE.

Code: 0x00.

This request/response type is contained in the header and signifies success. Here is an example:

Code: 0x80.

If the response is out-of-band, due to use of box.session.push(), then IPROTO_REQUEST_TYPE is IPROTO_CHUNK instead of IPROTO_OK.

Code: 0x8XXX (see below).

Instead of IPROTO_OK, an error response header has 0x8XXX for IPROTO_REQUEST_TYPE. XXX is the error code – a value in src/box/errcode.h. src/box/errcode.h also has some convenience macros which define hexadecimal constants for return codes.

To learn more about error responses, check the section Request and response format.

Since 2.11.0.

Code: -1.

An unknown request type. The constant is used to override the handler of unknown IPROTO request types. Learn more: box.iproto.override() and box_iproto_override.

Code: 0x01.

See space_object:select(). The body is a 6-item map.

If the ID of tspace is 512 and this is the fifth message, {conn}.``space.tspace:select({0},{iterator='GT',offset=1,limit=2}) will cause the following request packet:

In the examples, you can find actual byte codes of an IPROTO_SELECT message.

Code: 0x02.

See space_object:insert(). The body is a 2-item map:

For example, if the request is INSERT INTO {table-name} VALUES (1), (2), (3), then the response body contains an IPROTO_SQL_INFO map with SQL_INFO_ROW_COUNT = 3. SQL_INFO_ROW_COUNT can be 0 for statements that do not change rows, but can be 1 for statements that create new objects.

If the ID of tspace is 512 and this is the fifth message, {conn}.``space.tspace:insert{1, 'AAA'} will produce the following request and response packets:

The tutorial Understanding the binary protocol shows actual byte codes of the response to the IPROTO_INSERT message.

Code: 0x03.

See space_object:replace(). The body is a 2-item map, the same as for IPROTO_INSERT:

Code: 0x04.

See space_object:update().

The body is usually a 4-item map:

If the operation specifies no values, then IPROTO_TUPLE is a 2-item array:

Normally field numbers start with 1.

If the operation specifies one value, then IPROTO_TUPLE is a 3-item array:

Otherwise IPROTO_TUPLE is a 5-item array:

If the ID of tspace is 512 and this is the fifth message, {conn}.``space.tspace:update(999, {{'=', 2, 'B'}}) will cause the following request packet:

The map item IPROTO_INDEX_BASE is optional.

The tutorial Understanding the binary protocol shows the actual byte codes of an IPROTO_UPDATE message.

Code: 0x09.

See space_object:upsert().

The body is usually a 4-item map:

IPROTO_OPS is the array of operations. It is the same as the IPROTO_TUPLE of IPROTO_UPDATE.

IPROTO_TUPLE is an array of primary-key field values.

Code: 0x05.

See space_object:delete(). The body is a 3-item map:

Code: 0x08.

See conn:eval(). Since the argument is a Lua expression, this is Tarantool's way to handle non-binary with the binary protocol. Any request that does not have its own code, for example box.space.{space-name}:drop(), will be handled either with IPROTO_CALL or IPROTO_EVAL.

The tt administrative utility makes extensive use of eval.

The body is a 2-item map:

• For IPROTO_EVAL and IPROTO_CALL the response body will usually be an array but, since Lua requests can result in a wide variety of structures, bodies can have a wide variety of structures.

If this is the fifth message, conn:eval('return 5;') will cause:

Code: 0x0a.

See conn:call(). This is a remote stored-procedure call. /release/1.6 and earlier made use of the IPROTO_CALL_16 request (code: 0x06). It is now deprecated and superseded by IPROTO_CALL.

The body is a 2-item map. The response will be a list of values, similar to the IPROTO_EVAL response. The return from conn:call is whatever the function returns.

Code: 0x07.

For general information, see the Access control section in the administrator's guide.

For more on how authentication is handled in the binary protocol, see the Authentication section of this document.

The client sends an authentication packet as an IPROTO_AUTH message:

IPROTO_USERNAME holds the user name. IPROTO_TUPLE must be an array of 2 fields: authentication mechanism and scramble, encrypted according to the specified mechanism.

The server instance responds to an authentication packet with a standard response with 0 tuples.

To see how Tarantool handles this, look at net_box.c function netbox_encode_auth.

Code: 0x0c.

There is no Lua request exactly equivalent to IPROTO_NOP. It causes the LSN to be incremented. It could be sometimes used for updates where the old and new values are the same, but the LSN must be increased because a data-change must be recorded. The body is: nothing.

Since version 3.3.0.

Code: 0x11 The body is a 2-item map:

Code: 0x40.

See conn:ping(). The body will be an empty map because IPROTO_PING in the header contains all the information that the server instance needs.

Code: 0x49.

Clients send this message to inform the server about the protocol version and features they support. Based on this information, the server can enable or disable certain features in interacting with these clients.

The body is a 2-item map:

The response body has the same structure as the request body. It informs the client about the protocol version, features supported by the server, and a protocol used to generate user authentication data.

IPROTO_ID requests can be processed without authentication.