looking for help: frame definitions in SecureSession

Hi All,

I've been working in SecureSession (http://www.squeaksource.com/Cryptography) and I have worked on redefining the Vintage message definitions over these past months to a new frame specification that may be good to use across uses: internet, telecomm, multicore and with 4 tag bits, hoping that's helpful in some way with the vm. I have been thinking more about whether what I came up with could be improved. My apologies for fomenting such change in the spec. This spec can be found here: http://jmp.sh/zASyHlK.

The issue I face with the vintage protocol is there is no identifying information compared to the frame messageVersion to differentiate it as a vintage msg. I had not looked at the ASN1DER encoding of those vintage messages critically; on a quick look it looks like the "timeSent" field lines up with the messageVersion of the frame definition. This would be great if we could repurpose the timeSent as a msgVersion then send vintage traffic along with frame traffic, together.

On the frame definition of the 8 byte msgSpec, I think perhaps some changes would be good. In analysis, we don't need 6 bits for msgVersion, perhaps only 3 bits, so the multicast could go to 9 bits. The 8 bits of hash could be recast as the channel, or circuit, so we can multiplex traffic. This still leaves 64 different header type values for differentiation and allows 256 channels and 512 multicasts. What do you think? Are these good changes?

Old frame msgSpec definition: 8 bytes bit encoded

• 1st word, 4 bytes
• 4 bits : tags
• 6 bits : multicast
• 6 bits : messageVersion

• 2 bits : priority
• 6 bits : headerType
• 8 bits : hash
• 2nd word, 4 bytes
• 32 bits : messageSize (payload bytes = (messageSize - headerSize - 8 bytes msgSpec))

Proposed msgSpec definition: 8 bytes bit encoded

• 1st word, 4 bytes
• 4 bits : tags
• 9 bits : multicast
• 3 bits : messageVersion

• 2 bits : priority
• 6 bits : headerType
• 8 bits : channel
• 2nd word, 4 bytes
• 32 bits : messageSize (payload bytes = (messageSize - headerSize - 8 bytes msgSpec))

Best,
Robert

-- 
Robert
.  ..   ...    ^,^

I decided to change the msgSpec fields as described below, with some reordering and size/purpose changes. I published this as package version 100, and it is a major change. To make sure this basic 8-byte spec layout keeps forward, I've needed to redefine version 1. I am all ears if you think this is a good change or not.

Published msgSpec definition: 8 bytes bit encoded

• 1st word, 4 bytes
• 4 bits : tags
• 4 bits : frameVersion
• 2 bits : priority
• 6 bits : headerType

• 8 bits : multicast
• 8 bits : channel

• 2nd word, 4 bytes
• 32 bits : messageSize (payload bytes = (messageSize - headerSize - 8 bytes msgSpec))

thank you,
Robert

Hi All,

I've been working in SecureSession (http://www.squeaksource.com/Cryptography) and I have worked on redefining the Vintage message definitions over these past months to a new frame specification that may be good to use across uses: internet, telecomm, multicore and with 4 tag bits, hoping that's helpful in some way with the vm. I have been thinking more about whether what I came up with could be improved. My apologies for fomenting such change in the spec. This spec can be found here: http://jmp.sh/zASyHlK.

The issue I face with the vintage protocol is there is no identifying information compared to the frame messageVersion to differentiate it as a vintage msg. I had not looked at the ASN1DER encoding of those vintage messages critically; on a quick look it looks like the "timeSent" field lines up with the messageVersion of the frame definition. This would be great if we could repurpose the timeSent as a msgVersion then send vintage traffic along with frame traffic, together.

On the frame definition of the 8 byte msgSpec, I think perhaps some changes would be good. In analysis, we don't need 6 bits for msgVersion, perhaps only 3 bits, so the multicast could go to 9 bits. The 8 bits of hash could be recast as the channel, or circuit, so we can multiplex traffic. This still leaves 64 different header type values for differentiation and allows 256 channels and 512 multicasts. What do you think? Are these good changes?

Old frame msgSpec definition: 8 bytes bit encoded

• 1st word, 4 bytes
• 4 bits : tags
• 6 bits : multicast
• 6 bits : messageVersion

• 2 bits : priority
• 6 bits : headerType
• 8 bits : hash
• 2nd word, 4 bytes
• 32 bits : messageSize (payload bytes = (messageSize - headerSize - 8 bytes msgSpec))

Proposed msgSpec definition: 8 bytes bit encoded

• 1st word, 4 bytes
• 4 bits : tags
• 9 bits : multicast
• 3 bits : messageVersion

• 2 bits : priority
• 6 bits : headerType
• 8 bits : channel
• 2nd word, 4 bytes
• 32 bits : messageSize (payload bytes = (messageSize - headerSize - 8 bytes msgSpec))

Best,
Robert

-- 
Robert
.  ..   ...    ^,^

-- 
Robert
.  ..   ...    ^,^