<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
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.<br>
<br>
Published msgSpec definition: 8 bytes bit encoded<br>
<ul>
<li>1st word, 4 bytes</li>
<ul>
<li>4 bits : tags</li>
<li>4 bits : frameVersion</li>
<li>2 bits : priority</li>
<li>6 bits : headerType</li>
</ul>
</ul>
<ul>
<ul>
<li>8 bits : multicast</li>
<li>8 bits : channel</li>
</ul>
</ul>
<ul>
<li>2nd word, 4 bytes</li>
<ul>
<li>32 bits : messageSize (payload bytes = (messageSize -
headerSize - 8 bytes msgSpec))</li>
</ul>
</ul>
<p>thank you,<br>
Robert<br>
</p>
<br>
<div class="moz-cite-prefix">On 04/23/2016 03:01 PM, Robert Withers
wrote:<br>
</div>
<blockquote cite="mid:571BC68D.6060504@gmail.com" type="cite">
<meta http-equiv="content-type" content="text/html; charset=utf-8">
Hi All,<br>
<br>
I've been working in SecureSession (<a moz-do-not-send="true"
class="moz-txt-link-freetext"
href="http://www.squeaksource.com/Cryptography">http://www.squeaksource.com/Cryptography</a>)
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: <a moz-do-not-send="true"
class="moz-txt-link-freetext" href="http://jmp.sh/zASyHlK">http://jmp.sh/zASyHlK</a>.<br>
<br>
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.<br>
<br>
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?<br>
<br>
<meta http-equiv="content-type" content="text/html; charset=utf-8">
Old frame msgSpec definition: 8 bytes bit encoded<br>
<ul>
<li>1st word, 4 bytes</li>
<ul>
<li>4 bits : tags</li>
<li>6 bits : multicast</li>
<li>6 bits : messageVersion</li>
</ul>
</ul>
<ul>
<ul>
<li>2 bits : priority</li>
<li>6 bits : headerType</li>
<li>8 bits : hash</li>
</ul>
<li>2nd word, 4 bytes</li>
<ul>
<li>32 bits : messageSize (payload bytes = (messageSize -
headerSize - 8 bytes msgSpec))</li>
</ul>
</ul>
<br>
Proposed msgSpec definition: 8 bytes bit encoded<br>
<ul>
<li>1st word, 4 bytes</li>
<ul>
<li>4 bits : tags</li>
<li>9 bits : multicast</li>
<li>3 bits : messageVersion</li>
</ul>
</ul>
<ul>
<ul>
<li>2 bits : priority</li>
<li>6 bits : headerType</li>
<li>8 bits : channel</li>
</ul>
<li>2nd word, 4 bytes</li>
<li>32 bits : messageSize (payload bytes = (messageSize -
headerSize - 8 bytes msgSpec))</li>
</ul>
<p><br>
Best,<br>
Robert<br>
</p>
<pre class="moz-signature" cols="72">--
Robert
. .. ... ^,^</pre>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
Robert
. .. ... ^,^</pre>
</body>
</html>