<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">
<br><div><div>On Sep 4, 2007, at 12:04 , Tony Tung wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><font face="Verdana, Helvetica, Arial"><span style="font-size:12.0px">1) The magic byte is different, and also unique to request and response. We also maintain a notion of binary protocol versions for possible future (albeit limited) expansion.</span></font></blockquote><div><br class="webkit-block-placeholder"></div><div><span class="Apple-tab-span" style="white-space:pre"> </span>It was decided that the request and response magic should be different. I believe I added the definitions but didn't actually give them different values.</div><div><br class="webkit-block-placeholder"></div><blockquote type="cite"><font face="Verdana, Helvetica, Arial"><span style="font-size:12.0px"> 2) We specified the command IDs a bit differently, grouping them by request/response type.</span></font></blockquote><div><br class="webkit-block-placeholder"></div><div><span class="Apple-tab-span" style="white-space:pre"> </span>What is the value of this? Is it not more valuable to just list them sequentially so implementors can easily tell what the commands are without computing them?</div><div><br class="webkit-block-placeholder"></div><blockquote type="cite"><font size="2"><font face="Courier New"><span style="font-size:10.0px"> #define BP_QUIET BIT(3)</span></font></font></blockquote><div><br class="webkit-block-placeholder"></div><div><span class="Apple-tab-span" style="white-space:pre"> </span>I suggested this in the first meeting and it was rejected. The idea was to make commands (including quiet commands) with their specific semantics as needed. For example, the desirable semantics of a quiet get are that there is no response body unless there's a success. For a quiet set (if such a thing needs to exist), there should be no response body unless there's an error.</div><div><br class="webkit-block-placeholder"></div><blockquote type="cite"><font size="2"><font face="Courier New"><span style="font-size:10.0px"> // these commands go as an empty_req and return as an empty_rep.<br> BP_ECHO_CMD = (BP_E_E | FIELD(0x0, 0)),</span></font></font></blockquote><div><br class="webkit-block-placeholder"></div><span class="Apple-tab-span" style="white-space:pre"> </span>We had discussed both an echo (BP_S_S) and a noop (BP_E_E). I didn't implement echo, but my noop has your echo semantics, it seems.</div><div><br><blockquote type="cite"><font size="2"><font face="Courier New"><span style="font-size:10.0px"> BP_SERVERERR_CMD = (BP_E_S | FIELD(0x1, 0)), // this is actually not a<br> // command. this is solely<br> // used as a response when<br> // the server wants to<br> // indicate an error status.</span></font></font></blockquote><div><br class="webkit-block-placeholder"></div><div><span class="Apple-tab-span" style="white-space:pre"> </span>When does the server indicate an error status that's not in response to a command?</div><div><br class="webkit-block-placeholder"></div><blockquote type="cite"><span class="Apple-style-span" style="-webkit-text-stroke-width: -1; "> // these commands go as a string_req and return as an empty_rep.</span></blockquote><blockquote type="cite"><font size="2"><font face="Courier New"><span style="font-size:10.0px"> BP_FLUSH_REGEX_CMD = (BP_S_E | FIELD(0x0, 0)),</span></font></font></blockquote><div><br class="webkit-block-placeholder"></div><span class="Apple-tab-span" style="white-space:pre"> </span>Does this implementation exist? People have been asking for it a lot.</div><div><br><blockquote type="cite"><font size="2"><font face="Courier New"><span style="font-size:10.0px"> // these commands go as a string_req and return as a string_rep.<br> BP_STATS_CMD = (BP_S_S | FIELD(0x0, 0)),</span></font></font></blockquote><div><br class="webkit-block-placeholder"></div><div><span class="Apple-tab-span" style="white-space:pre"> </span>We discussed having more structure in the response to a stats command since there is structure in the stats result itself. It makes sense to me to have the response be a list of sorts.</div><div><br class="webkit-block-placeholder"></div><blockquote type="cite"><font face="Verdana, Helvetica, Arial"><span style="font-size:12.0px"> 3) We have no support for 64-bit arithmetic commands. We have retained decr (so far).</span></font></blockquote><br><div><span class="Apple-tab-span" style="white-space:pre"> </span>Decr was killed because it seemed mostly unnecessary and was semantically different (in implementation, anyway) from incr. I fixed the latter bug in my tree and made sure the incr amount was unsigned with the 64-bit patch.<br class="webkit-block-placeholder"></div><div><br class="webkit-block-placeholder"></div><div><span class="Apple-tab-span" style="white-space:pre"> </span>Obviously, decr still exists in spirit, as my client interface hasn't changed due to binary protocol implementation.<br class="webkit-block-placeholder"></div><br><blockquote type="cite"><font face="Verdana, Helvetica, Arial"><span style="font-size:12.0px"> 4) The return value for arithmetic commands is binary and not a string. I wasn’t at the hackathon during which this was decided so I’d be interested in finding out why a string is preferable.</span></font></blockquote><div><br class="webkit-block-placeholder"></div><div><span class="Apple-tab-span" style="white-space:pre"> </span>The string is required for the internal representation due to ``get'' requests expecting ascii representations of the numbers. As the arithmetic operations are already working on string values, it made sense to go ahead and return a value from incr the same way that the same value would be returned from a get.</div><div><br class="webkit-block-placeholder"></div><div><span class="Apple-tab-span" style="white-space:pre"> </span>I suppose we could pack the results into a 64-bit number as well, by modifying add_delta to provide the counter to the response, but I don't think there's a lot to gain here. As it is, I'm using an unmodified do_add_delta (well, with the 64-bit mods) for both text and bin.<br class="webkit-block-placeholder"></div><div><br class="webkit-block-placeholder"></div><div><span class="Apple-tab-span" style="white-space:pre"> </span>The other difference is that we're allowing counters to (optionally) be created using incr. At least one of the users of counters indicated he's sending an add and incr together to ensure the counter exists. It seems natural to put these things together. Based on values in your packet, you can either expect a NOT_FOUND sort of response, or an auto-created counter when incrementing a missing value.</div><br><blockquote type="cite"><font face="Verdana, Helvetica, Arial"><span style="font-size:12.0px"><br> Thanks,<br> Tony<br> <br> On 8/27/07 8:39 PM, "Dustin Sallings" <<a href="mailto:dustin@spy.net">dustin@spy.net</a>> wrote:<br> <br> </span></font><blockquote type="cite"><font face="Verdana, Helvetica, Arial"><span style="font-size:12.0px"><br> <br> I just got memcached passing all of my tests with the binary wire <br> protocol (tcp). Sorry it took me so long to get going on it.<br> <br> I've implemented this as a patch stack (using mercurial queues) over <br> trunk r608 with Evan Miller's 64-bit counter patch applied (since <br> everyone is excited by big numbers). I've got no idea where (if <br> anywhere) active development is going on. I can pick it up and move <br> it needed.<br> <br> I don't know what clients are ready. I haven't done a release of my <br> java client with binary protocol support yet, but I can roll out a <br> pre-release if someone wants to try it (all of my interop tests pass <br> between my java client and memcached in binary mode, so I just need <br> to clean it up a bit). My test python client is functional for at <br> least interactive use as well.<br> <br> <br> Known issues:<br> <br> I didn't implement a timeout on delete. I suppose I should, but do <br> people actually use that?<br> <br> I didn't implement a timeout on flush. I'd rather avoid that one if <br> possible because the semantics are really confusing.<br> <br> I basically ignored managed buckets because I have no idea how they <br> work.<br> <br> My 64-bit ntohl kind of thing might not work on big endian machines <br> (I haven't tried it yet). Moreover, I would hope something like that <br> would already exist somewhere, so I didn't bother making it fast.<br> <br> I've only implemented version, flush, noop, set, add, replace, get, <br> getq, delete, and incr. Besides stats (for which we have no clearly <br> defined packet format), there seem to be other commands in there that <br> don't make much sense to me.<br> <br> There may be more, but I don't know about them yet.<br> <br> --<br> Dustin Sallings<br> <br> <br> <br> </span></font></blockquote><font face="Verdana, Helvetica, Arial"><span style="font-size:12.0px"><br> </span></font> </blockquote></div><br><div> <span class="Apple-style-span" style="border-collapse: separate; border-spacing: 0px 0px; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; text-align: auto; -khtml-text-decorations-in-effect: none; text-indent: 0px; -apple-text-size-adjust: auto; text-transform: none; orphans: 2; white-space: normal; widows: 2; word-spacing: 0px; "><div>-- </div><div>Dustin Sallings</div><br class="Apple-interchange-newline"></span> </div><br></body></html>