<HTML>
<HEAD>
<TITLE>Re: binary protocol notes from the facebook hackathon</TITLE>
</HEAD>
<BODY>
<FONT FACE="Verdana, Helvetica, Arial"><SPAN STYLE='font-size:12.0px'>Agreed, and as we discussed last night, for UDP relying on the last get is difficult since you don&#8217;t know the exact length in advance. &nbsp;It may exceed the residual length of the packet you are currently constructing, so then you need to unwind it and potentially unwind the previous getq and redo it as a get. &nbsp;I think we can document that GET uncorks and that for datagram multigets ECHO is preferable but both ECHO and GET must be handled. &nbsp;(It&#8217;s no extra work from the server side to handle either)<BR>
<BR>
On 7/10/07 9:38 AM, &quot;Paul Querna&quot; &lt;chip@corelands.com&gt; wrote:<BR>
<BR>
</SPAN></FONT><BLOCKQUOTE><FONT SIZE="2"><FONT FACE="Monaco, Courier New"><SPAN STYLE='font-size:10.0px'>Brad Fitzpatrick wrote:<BR>
....<BR>
&gt; COMMANDS: &nbsp;(for cmd byte)<BR>
&gt; <BR>
&gt; &nbsp;&nbsp;get &nbsp;&nbsp;&nbsp;- single key get (no more multi-get; clients should pipeline)<BR>
&gt; &nbsp;&nbsp;getq &nbsp;&nbsp;- like get, but quiet. &nbsp;that is, no cache miss, return nothing.<BR>
&gt; <BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Note: clients should implement multi-get (still important for<BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;reducing network roundtrips!) as n pipelined requests, the<BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;first n-1 being getq, the last being a regular<BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;get. &nbsp;that way you're guaranteed to get a response, and<BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;you know when the server's done. &nbsp;you can also do the naive<BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;thing and send n pipelined gets, but then you could potentially<BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;get back a lot of &quot;NOT_FOUND!&quot; error code packets.<BR>
<BR>
This is missing the discussion about the GETQ putting the server into<BR>
'cork' mode, and any non-GETQ would uncork it. &nbsp;This would allow the<BR>
server to optimize its own IO without nearly as much pain.<BR>
<BR>
Also, as a client author, I really would prefer just having a NOOP or<BR>
ECHO command at end of the bulk GETQ, rather than having to special case<BR>
the last request. I guess I could just send a GET for a stats key or<BR>
something, but that seems weird.<BR>
<BR>
-Paul<BR>
<BR>
</SPAN></FONT></FONT></BLOCKQUOTE><FONT SIZE="2"><FONT FACE="Monaco, Courier New"><SPAN STYLE='font-size:10.0px'><BR>
</SPAN></FONT></FONT>
</BODY>
</HTML>