Freigeben über

Message Framing, Part 6

  • Artikel

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.

  • Part 2 (record type 0- version, record type 1- mode, record type 2- via)
  • Part 3 (record type 3- known encoding, record type 4- extensible encoding)
  • Part 4 (record type 9- upgrade request, record type 10- upgrade response, record type 11- preamble acknowledgment, record type 12- preamble end)
  • Part 5 (record type 5- unsized envelope, record type 6- sized envelope, record type 7- end)

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.

  • Received an unexpected record type
  • Version not recognized
  • Mode not recognized
  • Via too long
  • No endpoint at the specified via
  • Encoding not supported
  • Extensible encoding content type too long
  • Upgrade not supported
  • Message too large

I'll wrap up the series next time by covering the table of fault URIs and touching on a few miscellaneous topics.

Comments

  • Anonymous
    February 04, 2009
    Finally got enough snow to delay school for a couple of hours. Oslo/CSD/Queing/Azure/WCF Charles Young takes a closer look at the new CTP of Oslo that I reported the other day He also references this post for what's new and changed in the Oslo CTP Brian