Binary Encoding, Part 7

For the last part in the binary encoding series I'll cover how the use of the string table changes when the encoder is used in a sessionful manner. Here now are all of the past entries in the series:

• Binary Encoding, Part 1
• Binary Encoding, Part 2
• Binary Encoding, Part 3
• Binary Encoding, Part 4
• Binary Encoding, Part 5
• Binary Encoding, Part 6
• Binary Encoding Exercise
• Binary Encoding Exercise Answers

I covered in part 6 the use of a static string table for compactly representing text strings using an integer token. The static strings were assumed to be prearranged knowledge shared between the two sides so the strings themselves were never transmitted. Also, the token values in the static string table only had assignments for even numbers.

In some cases though, a string may appear repetitively in a message that is not one of the strings previously agreed to be shared. The dynamic string table is a way for the sender of the message to communicate the string once, creating an integer token that stands in place of the string in the future. All of these dynamically assigned strings fall into the odd numbers for string table token values.

The use of a dynamic string table is one of the options that must be specified when the two sides agree to exchange messages in the binary format. For example, in the previous series on message framing I listed off a number of known encodings for framing, including multiple versions of the binary encoding. The different binary encoding types specify whether a dynamic string table is being used. Other ways of communicating the use of the binary format require a similar mechanism, such as a specific MIME type.

When the two sides have agreed to use a dynamic string table, the string table accumulates over time for all of the messages in a session. The set of messages included in a session are another aspect that the two sides have to agree upon.

The string table initially contains only the entries from the static string table. Prior to each message in the session, a header is sent containing new string table entries. The header starts with the length of the header in bytes followed by any number of length-prefixed strings. The transmitted strings are added to the string table based on the order that they appear. The first transmitted string in a session is assigned the token value 1; the second transmitted string in a session is assigned the token value 3, and so on.

Once a string has been dynamically assigned an entry in the string table, the same record types that were used for referencing entries in the static string table can be used. The two kinds of strings aren't distinguished later when using them in a message.

WCF uses the dynamic string table for strings that it finds from the service contract (think of what you can guess will commonly appear in a message from the structural description, such as the service operation name or the tag names for wrapper elements). If you were building the messages yourself, you could of course substitute any strings you wanted though. For example, the message in the previous exercise included the string "Message". If we thought that that string would appear frequently, then we could assign it a dynamic string table entry using a message header such as:

0x08, 0x07, 0x4D, 0x65, 0x73, 0x73, 0x61, 0x67, 0x65

The message header includes one string. If that happened to be the first string presented in the session, then we could now use the token value 1 with one of the string table record types wherever the string "Message" would have appeared.