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.
- The initial relative TCP sequence number is 1
Interesting approach – standard TCP framing.