dpharris
commented
5 years ago Can we guarantee the order of TCP message-parts? If not, could we add sequence number?
Thanks David
On Thu, Mar 21, 2019 at 8:53 AM Robert Heller notifications@github.com wrote:
In reading TcpTransferTN and TcpTransferS, I have found a somewhat major error:
TcpTransferS talks about the flag word at the start of a OpenLCB Tcp message from the high bit to the low bit, briefly:
8000 -- OpenLCB/Link 4000 -- Chain 3000 -- Zero 0C00 -- Multipart: 0b00 single, 0b01 first, 0b11 center, 0b10 last 03FF -- Zero
But TcpTransferTN talks about these bits in the opposite order (page 2, Section 2.3, the yellow text starting around line 35 though line 45). The whole yellow text section needs to be rewritten.
I would propose something like this:
Flags field.
The MSB 0x8000 is an expansion flag used to (eventually) add link control messages. These might be needed for e.g. turning gateway-filtering on and off, loading/resetting remote diagnostic information, etc.
The 0x4000 bit indicates "chaining": Another prefix is next, before the body of the message.
The 0x0C00 bits provide a way of extending a single OpenLCB message across multiple TCP transfers. This might be used to e.g. simplify buffering and framing in CAN-Ethernet gateways. A single OpenLCB message that extends across multiple CAN frames is best accumulated into a single TCP transmission. If that's not possible due to buffering or other issues, it can be sent as multiple TCP transmissions using the 0x0C00 bits. When the bits are zero it is a single part message, when 0x0400 it indicates the first part of the message (there can be only one first part), when 0x0C00, it is a middle part of the message (there can be multiple middle parts), when it is 0x0800 it is the last part (there can be only one last part). The multiple parts must have matching MTIs, Source NIDs, and for addressed messages matching Destination NIDs. The message fragments should be combined in the order received.
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/openlcb/documents/issues/12, or mute the thread https://github.com/notifications/unsubscribe-auth/AAg4Sp9PuuQfL5k6if5N2el6dEyAgfsnks5vY6sBgaJpZM4cBxPW .
bakerstu
RobertPHeller
pabender
balazsracz
kiwi64ajs
In reading TcpTransferTN and TcpTransferS, I have found a somewhat major error:
TcpTransferS talks about the flag word at the start of a OpenLCB Tcp message from the high bit to the low bit, briefly:
8000 -- OpenLCB/Link 4000 -- Chain 3000 -- Zero 0C00 -- Multipart: 0b00 single, 0b01 first, 0b11 center, 0b10 last 03FF -- Zero
But TcpTransferTN talks about these bits in the opposite order (page 2, Section 2.3, the yellow text starting around line 35 though line 45). The whole yellow text section needs to be rewritten.
I would propose something like this:
Flags field.
The MSB 0x8000 is an expansion flag used to (eventually) add link control messages. These might be needed for e.g. turning gateway-filtering on and off, loading/resetting remote diagnostic information, etc.
The 0x4000 bit indicates "chaining": Another prefix is next, before the body of the message.
The 0x0C00 bits provide a way of extending a single OpenLCB message across multiple TCP transfers. This might be used to e.g. simplify buffering and framing in CAN-Ethernet gateways. A single OpenLCB message that extends across multiple CAN frames is best accumulated into a single TCP transmission. If that's not possible due to buffering or other issues, it can be sent as multiple TCP transmissions using the 0x0C00 bits. When the bits are zero it is a single part message, when 0x0400 it indicates the first part of the message (there can be only one first part), when 0x0C00, it is a middle part of the message (there can be multiple middle parts), when it is 0x0800 it is the last part (there can be only one last part). The multiple parts must have matching MTIs, Source NIDs, and for addressed messages matching Destination NIDs. The message fragments should be combined in the order received.