Past entries that you should have read by now:
I've so far only talked about what happens when things go right when messages are exchanged using the framing format. There's one more record type to describe that is used to communicate errors: record type 8 for fault records. If you go back through the previous articles and compare them to the list of records in part 1, you'll see that we've covered all of the other 12 record types.
A fault record is sent when an error is encountered while processing a message frame in the framing format. Sending a fault record is optional to let the other party know that something is wrong. Whether or not a fault record is sent, the framing connection has to be closed after the error. However, the use of faults may help the two sides to resynchronize and recycle the underlying network connection by starting a new framing session.
A fault record starts with the byte 8 followed by the size of the fault string and followed by the fault string itself. A fault string is a standard URI and encoded using UTF-8 rather than an actual description of the fault itself. The fault receiver is responsible for taking some recovery action based on the fault string or translating the fault string into an error message for the user. The size is encoded in the usual way.
Here are some of the various reasons why a fault may occur.
I'll wrap up the series next time by covering the table of fault URIs and touching on a few miscellaneous topics.