IPC protocol details

For advanced users

This information is provided for debugging and troubleshooting purposes only. You do not need to understand the low-level protocol for typical q development.

You can view the raw byte representation of a serialized q object with -8!object.

Handshake

1. A client opens a socket to the server.
2. The client sends a null-terminated ASCII string in the format "username:password\C", where \C is a single capability byte that indicates the client's features (for example, support for compression, UUIDs, and large messages).
3. If the server rejects the credentials, it closes the connection.
4. If the server accepts, it responds with a single byte representing the common capability level of both client and server.

Capability bytes:

Byte	Features supported
0	No compression, timestamp, timespan, or UUID (V2.5)
1--2	Compression, timestamp, timespan (V2.6--2.8)
3	Compression, timestamp, timespan, UUID (V3.0)
5	Support for messages > 2GB; vector counts must be ≤ 2 billion
6	Support for messages > 2GB; vector counts can be > 2 billion

Client compatibility

Java and C# clients have array length limits that make capabilities 5 and 6 incompatible with their standard object models. Ensure you are using a compatible capability level when interfacing with these clients.

Compression

An outgoing message is automatically compressed if all of the following conditions are met:

• The uncompressed data is larger than 2000 bytes.
• The connection is not to localhost or 127.0.0.1.
• The connection is not a Unix Domain Socket (UDS).
• The compressed data is less than half the size of the uncompressed data.

The compression algorithm is a variant of Lempel-Ziv. A reference implementation is available in the official q Java API.