I agree.&nbsp; Thats one thing I noticed about the protocol when I was reading my email on the train this morning.&nbsp; <br><br>Keeping the original structure would make it difficult to change the fixed-width parameters given to a command.&nbsp; 
<br><br>Having an offset would mean that the key can be found much easier.&nbsp; However, care should be taken that the offset given doesnt go out of the bounds of the message.&nbsp; I&#39;m not in total favour of an offset either, because in this case, you&#39;re basically moving the calculation from the server to the client.
<br><br>What I prefer is:<br>&nbsp;* Magic byte / version<br>&nbsp;* Cmd byte<br>&nbsp;* 4 byte opaque id.<br>&nbsp;* Key len byte&nbsp;&nbsp;(if no key, 0)<br>&nbsp;* key, if key length above is non-zero.<br>&nbsp;* 4 byte body length (not including reserved byte at the end)
<br>&nbsp;* [ cmd-specific fixed-width fields ]<br>&nbsp;* [ cmd-specific variable-width field ]<br>&nbsp;* Reserved byte (should be 0)<br>
<br>What I additionally prefer, is a total packet length after the magic byte, but that might meet substantially more debate.<br><br>Note: I&#39;m assuming that all variable length fields will have a representative length byte(s) somewhere in the protocol before it.
<br><br><div><span class="gmail_quote">On 7/11/07, <b class="gmail_sendername">Dustin Sallings</b> &lt;<a href="mailto:dustin@spy.net">dustin@spy.net</a>&gt; wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>On Jul 10, 2007, at 9:23, Brad Fitzpatrick wrote:<br><br>&gt; REQUEST STRUCTURE:<br>&gt;<br>&gt;&nbsp;&nbsp; * Magic byte / version<br>&gt;&nbsp;&nbsp; * Cmd byte<br>&gt;&nbsp;&nbsp; * Key len byte&nbsp;&nbsp;(if no key, 0)<br>&gt;&nbsp;&nbsp; * Reserved byte (should be 0)
<br>&gt;<br>&gt;&nbsp;&nbsp; * 4 byte opaque id.&nbsp;&nbsp;(will be copied back in response; means<br>&gt; nothing to server)<br>&gt;<br>&gt;&nbsp;&nbsp; * 4 byte body length (network order; not including 12 byte header)<br>&gt;<br>&gt;&nbsp;&nbsp; [ cmd-specific fixed-width fields ]
<br>&gt;<br>&gt;&nbsp;&nbsp; * key, if key length above is non-zero.<br>&gt;<br>&gt;&nbsp;&nbsp; [ cmd-specific variable-width field ]<br><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;I found a problem when implementing this.&nbsp;&nbsp;Given the above<br>structure, we always know the length of a key, but we can&#39;t know the
<br>location of a key unless we know how to process the given command.<br><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;I don&#39;t know that this is a huge problem, but it thwarted some of my<br>generic lower-level packet handling code in my test server.
<br><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Perhaps we could resurrect the reserved byte and use it as a fixed-<br>field word (or byte) count?&nbsp;&nbsp;I remember this coming up in the<br>discussion, but I think we decided it was redundant as the command<br>
should know what its headers are.<br><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Any opinions?<br><br>--<br>Dustin Sallings<br><br><br></blockquote></div><br><br clear="all"><br>-- <br>&quot;Be excellent to each other&quot;