It seems obvious that the data in our web services needs to be framed. In the good old days, where all transport was HTTP this was rather trivial: HTTP headers are rich, and can describe Content-Type, Length etc.

But what happens if you select e.g. the net.tcp transport channel in Indigo?

Well, after pointing ethereal to the wire exchange, I came to the following conclusions:

• All session relevant settings (charset, etc.) are exchanged during the connection setup
• The length of the data is framed based on the relative TCP sequence number:
  • The initial relative TCP sequence number is 1
  • The next relative TCP sequence number is computed by adding the number of Bytes in the packet to the current TCP sequence number.

Interesting approach - standard TCP framing.