On 13/2/2024 7:32 pm, Sebastian Huber wrote:
> Hello Chris,
>
> sorry for the delay.
>
> On 07.02.24 00:56, Chris Johns wrote:
>> On 5/2/2024 9:13 pm, Sebastian Huber wrote:
>>> Hello Chris,
>>>
>>> thanks for having a look at it.
>>>
>>> On 02.02.24 00:14, Chris Johns wrote:
Hi,
Thanks for the updated documentation, protocol and use cases. It has
helped.
Now
I understand some of the context I have raised further questions about it I
feel
we should resolve. Without a protocol version number being exchanged it
limits
how we can grow and develop this protocol beyond where it is.
On 26/1/2024 6:23 am, Sebastian Huber wrote:
> The RTEMS Test Framework packet processor provides a simple mechanism to
> exchange reliable and in-order data through transmitting and receiving
> one character at a time.
>
> The packet processor does not buffer data. The processor uses a
> stop-and-wait automatic repeat request method. There is at most one packet
> in transmission. The data transfer is done using a single character input
> and output method. The protocol uses 12-bit sequence numbers, so a host
> could use a sliding window method to increase throughput. All integers
> and
> data are base64url encoded. A 24-bit CRC is used to ensure the data
> integrity. The '{' character starts a packet. The '}' character
> terminates
> a packet. The '#' character prefixes a 24-bit CRC value. The ':'
> character
> separates fields. The '+' character prefixes data fields.
Is the line encoding a subset of the ASCII character set? Is the line
disciple
raw?
>>>
>>> yes, only ASCII (7-bit) is used. The processor uses a character input/output
>>> handler. It is up to the user to do the transfer. It could be for example
>>> also
>>> CAN or UDP packets.
>>
>> I think adding something about this will help the definition of the protocol.
>
> Ok, I will add this to the group description.
>
>>
I have reviewed the protocol as it is and I have some suggestions. The data
link
layer messages are mixed with the pay load messages. If the messages
followed:
{<12-bit seq><12-bit ack>:[:[data]]]#<24-bit CRC>}
where:
is `H`, `A`, `R` or `P` are data link packets and `P` for payload
can
contain `J`, `L`, `S` etc for the test and chain loader protocol. For
example:
{<12-bit seq><12-bit ack>:P:J:<64-bit address>#<24-bit CRC>}
>>>
>>> In my proposal, the payload has its own CRC so that you can first validate
>>> the
>>> header before you do something with the payload.
>>
>> How do you validate the header? Protocols like GFP have a simple length
>> encoded
>> into the start of the message to frame it and to allow sync/hunting to
>> happen to
>> resync when errors happen and is more robust than pattern matching. GFP is
>> unique because it byte aligns bit level streams when implemented in hardware,
>> something that is not important here.
>
> The header is validated by the state machine and the 24-bit CRC. The a '{'
> always starts the processing of a new packet.
Oh I had not considered the `{` was an actual character on the line and thought
it was some syntax used to describe the protocol. Seeing it I am reminded of the
MS DAP protocol and it's header ...
https://microsoft.github.io/debug-adapter-protocol/overview and scroll down to
Content Part and Example.
>> Is there an assumption the link is of a good quality and error free?
>
> No, the link can be noisy. We had for example occasional data loss via an USB
> UART in a VM.
OK, so being able to resync is important. Now I understand `{` is unique and a
starting delimiter it is easier see the recovery process.
Note, `P` could be a protocol id and so `T` could denote "test and chain
loader".
[:] denotes this is optional depending on pay load data being present or it
could mean data link vs payload packets, what ever works here.
> The following packets are defined:
>
> * hello: {<12-bit seq><12-bit ack>:H#<24-bit CRC>}
Are you able to have the `H` be a query and return data? A hello that
contains
protocol versioning data is always useful for long lived protocols. Version
numbering should be 1, 2, 3, 4 etc and 0 is reserved.
>>>
>>> Adding a protocol version to the hello message is a good idea.
>>>
> * acknowledge: {<12-bit seq><12-bit ack>:A#<24-bit CRC>}
Does this ack all seq numbers up to this number?
>>>
>>> Yes, it is like in TCP, however, currently only a stop-and-wait automatic
>>> repeat
>>> request method is implemented so that we don't need buffers.
>>
>> Great and please add this as a note to the doco.
>
> I think this is already there.
>
>>
> * reject: {<12-bit seq><12-bit ack>
> :R:<12-bit seq of rejected packet>#<24-bit CRC>}
Are the `<>` f
