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
      o 4 bits : tags
      o 4 bits : frameVersion
      o 2 bits : priority
      o 6 bits : headerType

      o 8 bits : multicast
      o 8 bits : channel

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

thank you,
Robert


On 04/23/2016 03:01 PM, Robert Withers wrote:
> 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
>       o 4 bits : tags
>       o 6 bits : multicast
>       o 6 bits : messageVersion
>
>       o 2 bits : priority
>       o 6 bits : headerType
>       o 8 bits : hash
>   * 2nd word, 4 bytes
>       o 32 bits : messageSize (payload bytes = (messageSize -
>         headerSize - 8 bytes msgSpec))
>
>
> Proposed msgSpec definition: 8 bytes bit encoded
>
>   * 1st word, 4 bytes
>       o 4 bits : tags
>       o 9 bits : multicast
>       o 3 bits : messageVersion
>
>       o 2 bits : priority
>       o 6 bits : headerType
>       o 8 bits : channel
>   * 2nd word, 4 bytes
>   * 32 bits : messageSize (payload bytes = (messageSize - headerSize -
>     8 bytes msgSpec))
>
>
> Best,
> Robert
>
> -- 
> Robert
> .  ..   ...    ^,^

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20160423/47e2682f/attachment.htm