Refinements.. Re: SecureSession protocol version 1.0 ( was Re: [Vm-dev] Re: SecureSession frame types)

[Robert Withers]

I call these evolutions refinements.  A few more here, pardon the bandwidth:

`1 - It was unspecified but the 4 tag bits can have 16 values, 1 for 
this protocol. The availability of 15 other protocols is a feature for 
open-source development.
`2 - a header is easily defined for different transports and networks.
`3 - the header of a FEC message is separately FEC encoded and 
interleaved with RS(15,9), so 30 bytes for the msgSpec and header, 
followed by the rsMode specified FEC encoding of the payload, padded out 
from msgSize.

thank you,
robert


On 12/21/2015 08:42 PM, Robert Withers wrote:
> I updated with all the feedback and here is a version 1.0 pdf 
> specification. I appreciate any comments or suggestions you may have 
> for this.
>
>     https://www.dropbox.com/s/ywu9pjxrfvg1hys/FrameTypes.pdf?dl=0
>
>
> Thank you,
> Robert
>
> On 12/20/2015 10:51 AM, Robert Withers wrote:
>> More, sorry. I left out the msgSize in the FEC spec. Let me reorder 
>> the tagging, fit the 3 bytes of normal msgSpec into 4bytes and thusly...
>>
>>
>> ---Default non-FEC msgSpec + header + payload layout:
>>
>> - 8bytes (X) messageSpecification...
>> -
>> - (32bits...)
>> - 4bits tagging
>> - 6bits multicastSymbol
>> - 6bits messageVersion
>> - 2bits sanguinity
>> - 6bits headerType "Implies Y header size. NOTE: except for FEC 
>> encodings"
>> - 8bits unused
>> - (32bits...)
>> - 4bytes messageSize (X+Y+Z) (Z bytes = (messageSize - headerSize(Y) 
>> - 8bytes msgSpec (X = 8))
>> -
>> - Ybytes message header 
>> https://www.dropbox.com/s/ywu9pjxrfvg1hys/FrameTypes.pdf?dl=0
>> -
>> - Zbytes message payload
>>
>>
>>
>> Special FEC coded 64bit <msgSpec + header> + payload layout, for 
>> 64bit alignment:
>>
>> - 8bytes (X) message specification...
>> -
>> - (32bits...)
>> - 4bits tagging
>> - 6bits multicastSymbol
>> - 6bits messageVersion
>> - 2bits sanguinity
>> - 6bits FEC message type "NOTE: this means different layout"
>> - 2bits rsMode
>> - 6bits partial blockCount
>> - (32bits...)
>> - 4bits blockCount           "NOTE: for 1MB encoded/982KB data - 
>> blockCount * blockCodeBytes = Z"
>> - 20bits messageSize (X+Y+Z) (Z bytes = (messageSize - headerSize(Y) 
>> - 8bytes msgSpec (X = 8))  "NOTE: this can specify 1MB data"
>> - 8bits primitivePolynomial spec (good for our current rsModes)
>> -
>> - Y = 0
>> -
>> - Zbytes-sized payload
>>
>> Ok, that's what it is I think, this proposal.
>>
>> robert
>>
>>
>>
>> On 12/20/2015 10:33 AM, Robert Withers wrote:
>>> ---Default non-FEC msgSpec + header + payload layout:
>>>
>>> - 6bits multicastSymbol
>>> - 2bits sanguinity
>>> - 6bits messageVersion
>>> - 6bits headerType "NOTE: except for FEC encodings"
>>> - 4bytes messageSize
>>> - Xbytes header
>>> -
>>> - (messageSized - headerSize - 7specBytes) Bytes-sized payload
>>>
>>>
>>> Special FEC coded 64bit <msgSpec + header> + payload layout, for 
>>> 64bit alignment:
>>>
>>> - (32bits...)
>>> - 6bits multicastSymbol
>>> - 2bits sanguinity
>>> - 6bits messageVersion
>>> - 6bits FEC message type "NOTE: this means different layout"
>>> - 2bits rsMode
>>> - (32bits...)
>>> - 10bits blockCount           "NOTE: for 1MB encoded/982KB data"
>>> - 20bits messageSize        "NOTE: this can specify 1MB data plus
>>> - 8bits primitivePolynomial spec (good for our current rsModes)
>>> - 4bits tagging
>>> -
>>> - (messageSized - headerSize - 4specBytes) OR (blockCount * rsMode's 
>>> blockCodeBytes) Bytes-sized payload
>>
>
> -- 
> . ..  ...   ^,^    robert
> Go Panthers!

-- 
. ..  ...   ^,^    robert
Go Panthers!

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20151221/1c01a73c/attachment.htm