Stream Protocol - Dest_Stream_ID vs Src_Stream_ID

[dpharris]

I note that the Frame Format in 7.1 Stream Data Send uses the Destination_Stream_ID, but the accompanying discussion talks about using the Source_Stream_ID.
I am not sure which is better, but would have thought using the Destination_Stream_ID would allow the destination0node the option of directly using this to access its buffers, while using the Source_Stream_ID would require a look-up to find the buffer.

From the source-node's point of view, either would seem equally easy to use.

[balazsracz]

it has to be the destination stream id, precisely for the reason you outlined.

[dpharris]

In S it says: 145 Stream Data Send messages are sent on a CAN network using the Frame Type of 7 (Stream Data), the Destination node alias and the Source node alias in the CAN header, and the Destination Stream ID in the first data byte. BUT: 211 On CAN, the Stream Data Send message does not carry the Destination Stream ID field. Messages to CAN get split into frames and forwarded without the field. Messages from CAN have to have it inserted by the gateway as part of the translation process. The gateway can do this as part of the (optional) buffer accumulation from frames into larger transfers.

In the TN it says: 215 ... Although initially consider, this it thought to be too inflexible. Instead, we chose a format where the Source Stream ID is carried, reducing the payload to seven bytes per frame.

(Note "consider" should be "considered")

[dpharris]

While I am at it, in TN: 4 Some wire protocols can supoprt only very short The typo should be "support"

[balazsracz]

There are a ton of other problems with the stream protocol text, I documented these in https://docs.google.com/document/d/1GPjkWChdA9mG0e4cz6jdMAx_k0xja40MHQnPv2HbRP0/edit#heading=h.tniqljzbkn1b and in https://github.com/openlcb/documents/issues/56

If you want to work on the stream documents, you should start by

• comparing the S/TN with the WN
• rolling back the S/TN to the state of message definitions that's in the WN. (This may have to be a rollback in github actually, throwing away all the edits that Stuart and I made in the last 10 years).

Then we can start from a clean plate.