<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
Say, why not keep the multicastSymbol and the 3byte msgSpec, with 4
6bit fields. Keep the size field at 4bytes. This is 7bytes and will
fit a 64bit register with a little headroom, if it's an immediate
value or wahtever is done.<br>
<br>
---<br>
Free association thinking about FEC specification follows...<br>
<br>
Lookingi nto the FEEC header it is 5 bytes, but that's too big!!
Not needed! How about 2bytes blockCount? <br>
<br>
With RS(255,223), the current largest, and 2 bytes of blockCount,
with 4 RS chunks per block, that's 1020bytes encoded per block
(892bytes data)...munch, munch, munch...67MB of FEC coded size or
58MB data per message. This seems reasonable to restrict it to this
size. If you've more then your app better be fragmenting its
communications in healthy sized chunks...least that's how I'm
thinking about it.<br>
<br>
Alright then, lets try to fit the msgSpec and the FECSpec into 1
dedicated 64bit register, maybe no tags....rsCode values can be
restricted to 4, so 2bits. 10bits for blockCount = 1 MB FEC
encoded/913 KB raw. Is that reasonable to limit it so and require
higher fragmentation?? That would be a session layer activity.
Well, that's 12 bits. If we knock sanguinity back to 2 bits (FLASH,
IMMEDIATE, PRIORITY, ROUTINE), that's 32bits with a max of 1MB
specified. 20bit size would do it, leaving 12bits of tag space,
perhaps the primary polynomial coefficients could go there, with
room to spare.<br>
<br>
This means the msgSpec layout for FEX enabled comms is different
than for all other messages not error correction encoded.<br>
<br>
---Default non-FEC msgSpec + header + payload layout:<br>
<br>
- 6bits multicastSymbol<br>
- 2bits sanguinity<br>
- 6bits messageVersion<br>
- 6bits headerType "NOTE: except for FEC encodings"<br>
- 4bytes messageSize<br>
- Xbytes header<br>
-<br>
- (messageSized - headerSize - 7specBytes) Bytes-sized payload<br>
<br>
<br>
Special FEC coded 64bit <msgSpec + header> + payload layout,
for 64bit alignment:<br>
<br>
- (32bits...)<br>
- 6bits multicastSymbol<br>
- 2bits sanguinity<br>
- 6bits messageVersion<br>
- 6bits FEC message type "NOTE: this means different layout"<br>
- 2bits rsMode<br>
- (32bits...)<br>
- 10bits blockCount "NOTE: for 1MB encoded/982KB data"<br>
- 20bits messageSize "NOTE: this can specify 1MB data plus <br>
- 8bits primitivePolynomial spec (good for our current rsModes)<br>
- 4bits tagging<br>
- <br>
- (messageSized - headerSize - 4specBytes) OR (blockCount * rsMode's
blockCodeBytes) Bytes-sized payload<br>
<br>
<br>
Is this complexity desired, I would ask you? If it is, is this the
right layout?<br>
<br>
thank you,<br>
robert<br>
<br>
<br>
On 12/20/2015 09:48 AM, Robert Withers wrote:<br>
<blockquote cite="mid:5676BFA0.10403@gmail.com" type="cite">
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
To sort of summarize, then, with this msgSpec, including overall
size, structure and priority (1 / sanguinity) specified in 6 or 7
bytes, will fit a 64bit register, with room, for low-level
routing. Add a 32bit register to the 64bit register, and you can
fit the 11 or 12 bytes to fully specify the FEC encoding, for
hardware assisted en/de/coding. I thought this may be important.
On the right track?<br>
<br>
thanks ,<br>
robert<br>
<br>
<div class="moz-cite-prefix">On 12/20/2015 09:33 AM, Robert
Withers wrote:<br>
</div>
<blockquote cite="mid:5676BC53.4050800@gmail.com" type="cite">
<meta content="text/html; charset=utf-8"
http-equiv="Content-Type">
Ok, let me make one last change to this 7 byte alternate
proposal for the message specification. In the first 3 bytes
with 4 fields, use supersymmetry to specify 6bits per field. SO
the alternate would look like below...<br>
<br>
<div class="moz-cite-prefix">The whole point of the multicast
symbol is to provide for low-level routers to not even have to
decode the asn.1 header and distinguish all our message and
header types. Just grab the first byte and mask the upper
6bits and shift, there is a destination specifier, at least in
the large, as an alternate tunneling capability and would
support reuse of 4byte IP addresses for NAT. If we loose that
and knock sanguinity back to 2bits, then we are down to a 6
byte spec + payload. I'm mulling iot over, obviously.<br>
<br>
<small><b><big><big><big><font face="DejaVu Serif">msgSpec: 7
bytes binary encoded</font></big></big></big></b></small><br>
</div>
<ul>
<li><big>HeaderSpecification: 3 bytes</big></li>
<ul>
<li>multicastSymbol: 6 bits</li>
<li>sanguinity: 6 bits</li>
</ul>
<ul>
<li>msgVersion: 6 bits</li>
<li>hdrType: 6 bits</li>
</ul>
<li><big>msgSize: 2nd word, 4 bytes</big></li>
<ul>
<li>4 bytes (total size with msgSpec, header, payload sizes)</li>
</ul>
</ul>
<br>
<br>
<div class="moz-signature">-- <br>
<div align="left">. .. .. ^,^ robert </div>
</div>
</blockquote>
<br>
<div class="moz-signature">-- <br>
<div align="left">. .. .. ^,^ robert </div>
</div>
</blockquote>
<br>
<div class="moz-signature">-- <br>
<div align="left">. .. .. ^,^ robert
</div>
</div>
</body>
</html>