I introduced you to HTCP in Section 8.3. That section mostly talked about how HTCP compares to ICP, as well as some of its other characteristics. The information in this appendix is primarily written for developers who want to implement HTCP in their own products. It might also be useful to someone trying to debug an HTCP-related problem. In the following sections, we’ll look at the structure of HTCP messages and values for all the fields. RFC 2756 is the authoritative specification of HTCP Version 0.0.
An HTCP message consists of three sections: HEADER, DATA, and AUTH. All multioctet fields are encoded in network byte order.
Figure D-1 shows the four-octet, fixed-size HTCP HEADER section. The LENGTH field specifies the size of the UDP message, and it should be equal to the number of octets written to and read from the network. MAJOR and MINOR specify the protocol version the sender is using. A change in the minor version number must not affect compatibility. In particular, when a reserved field is placed into service, the minor version number is incremented. When new fields or identifiers are added, the major version number is incremented.
Figure D-1. HTCP HEADER format
The DATA section, shown in Figure D-2, is where all the interesting stuff happens. It consists of eight fixed-format octets followed ...