This section describes the NDB
Protocol
message types, their function, and their structure.
Naming Conventions. Message names are constructed according to a simple pattern which should be readily apparent from the discussion of request and response types in the previous section. These are shown in the following matrix:
Table 3.1 NDB Protocol messages, with REQ, CONF, and REF message names
Operation Type | Request (REQ ) |
Response: Success (CONF ) |
Response: Failure (REF ) |
---|---|---|---|
Primary Key Lookup (TCKEY ) |
TCKEYREQ |
TCKEYCONF |
TCKEYREF |
Unique Key Lookup (TCINDX ) |
TCINDXREQ |
TCINDXCONF |
TCINDXREF |
Table or Index Scan (SCANTAB ) |
SCANTABREQ |
SCANTABCONF |
SCANTABREF |
Result Retrieval (SCAN_NEXT ) |
SCAN_NEXTREQ |
SCANTABCONF |
SCANTABREF |
Transaction Record Acquisition (TCSEIZE ) |
TCSEIZEREQ |
TCSEIZECONF |
TCSEIZEREF |
Transaction Record Release (TCRELEASE ) |
TCRELEASEREQ |
TCRELEASECONF |
TCRELEASEREF |
CONF
and REF
are shorthand
for “confirmed” and “refused”,
respectively.
Three additional types of messages are used in some instances of inter-node communication. These message types are listed here:
A
KEYINFO
message contains information about the key used in aTCKEYREQ
orTCINDXREQ
message. It is employed when the key data does not fit within the request message.KEYINFO
messages are also sent for index scan operations in which bounds are employed.-
An
ATTRINFO
message contains nonkey attribute values which does not fit within aTCKEYREQ
,TCINDXREQ
, orSCANTABREQ
message. It is used for:Supplying attribute values for inserts and updates
Designating which attributes are to be read for read operations
Specifying optional values to read for delete operations
A
TRANSID_AI
message contains data returned from a read operation; in other words, it is a result set (or part of one).