The almost last article in the series is a bit of data and roundup to catch a few miscellaneous topics. There’s been some interest in working through a few example messages so I may do a later part or two later for that.
Past entries that you should have read by now:
- Next Week, a Series
- Message Framing, Part 1
- Message Framing, Part 2
- Message Framing, Part 3
- Message Framing, Part 4
- Message Framing, Part 5
- Message Framing, Part 6
The fault strings mentioned in part 6 look mostly the same for each of the faults that we use. Each fault string is a standard URI beginning with http://schemas.microsoft.com/ws/2006/05/framing/faults/ followed by the name of the fault. The fault names we use include a few that are defined in the code but never placed on the wire and are:
Most are fairly self-explanatory from the name.
The four transfer modes are called singleton (mode 1), duplex (mode 2), simplex (mode 3), and singleton sized (mode 4). I described modes 1 and 2, which are used for TCP, in part 2.
Mode 1 is used for transferring streamed TCP messages. A mode 1 transfer looks like this: version, mode, via, encoding, upgrades, preamble end, one unsized envelope, end.
Mode 2 is used for transferring buffered TCP messages. A mode 2 transfer looks like this: version, mode, via, encoding, upgrades, preamble end, any number of sized envelopes, end.
Mode 3 is used for transferring multiple messages as a group with MSMQ called a sessiongram. A mode 3 transfer looks like this: version, mode, via, encoding, any number of sized envelopes, end.
Mode 4 is used for transferring single messages with MSMQ. A mode 4 transfer looks like this: version, mode, via, encoding, raw message bytes.
I can’t think of much more to say about message framing. You should be able to build an implementation of your own now with some minimal testing and inspection of the messages that get exchanged.