Interpreting Data Packet Diagrams
This topic describes the data packet diagrams used in this protocol documentation and the conventions used in the documentation to represent the fields in the packet.
The protocol documentation uses data packet diagrams to represent data packets and their fields graphically. These diagrams are designed to help you to visualize the data packet, but they are not exact replicas of the data packets as they appear on the wire.
The following graphic shows a sample data packet diagram.
A data packet diagram is composed of a header row and one or more field rows.
The header row shows the zero-based bytes in the first 32 bits (four bytes) of the packet. The following graphic shows the header row of a data packet diagram.
Below the header rows are the field rows. The field rows represent the fields in the data packet. Each field in the diagram occupies the approximate length that the data in that field would occupy in an actual data packet.
The first field row represents the fields that occupy the first four bytes in the packet. The following graphic shows the first field row in the sample data packet diagram.
When packets are longer than 32 bits (four bytes), the remaining bytes are displayed as additional rows in the diagram. To interpret the data packet diagram, imagine that the beginning of each row is concatenated to the end of the previous row to form a single data stream.
For example, in the following graphic, the wNormalizedFlag field in the fourth field row immediately follows the wCursorModel field, which is shown at the end of the third field row.
When a field is too long to fit in its row, it is continued on the next row. The continuation of a field can be represented by a blank field or by text that explains the continuation.
Continuation text is black text and is not a link. The field names are displayed in colored text to indicate that they link to the field descriptions below them on the page.
For example, in the following sample diagram, the guidResultDescription field, which occupies 16 bytes, is represented by one byte in the first field row, a guidResultDescriptor cont'd for 3 rows entry in the second field row that represents twelve bytes (three rows of four bytes each), and three blank bytes in the third row that represent the final three bytes of the field.
In another example, shown in the following sample diagram, the two-byte nTotalColumns field is represented by one byte at the end of the fourth field row and one byte at the beginning of the fifth field row.
When a field is of variable length, such as the wOrderByColumns field in the following sample diagram, it is represented by one or more bytes in one row and a variable length data entry in the following row.