Nick Sieger: RubyConf: Rinda in the Real Worldtag:blog.nicksieger.com,2005:TypoTypo2010-11-22T18:11:21+00:00Nick Siegerurn:uuid:ec8eface-3fb9-477d-8ad8-e91e4c5c9a1d2006-10-21T19:01:35+00:002010-11-22T18:11:21+00:00RubyConf: Rinda in the Real World<p><em>Speaker: <a href="http://www.vanderburg.org/">Glenn Vanderburg</a></em></p>
<p>Rinda is a distributed coordination system, by Masatoshi SEKI, based on work by David Gelernter (called Linda). It’s similar to JavaSpaces, but more in the Ruby spirit. It uses DRb for communication (also by Seki-san).</p>
<p>There are several existing tutorials on Rinda, but none with a broad, real-world applicability. As Glenn started to go deeper with Rinda, flaws began to be exposed.</p>
<h2>Rinda Basics</h2>
<ul>
<li>The <strong>TupleSpace</strong> is in the conceptual middle, as a bag of tuples “arrays”. Participants can write tuples into the space, or take them out (usually according to a set of conditions).</li>
<li><strong>Tuples</strong> are usually requests to do some work by some unknown requester, or responses to that work.</li>
<li>A <strong>RingServer</strong> is a broadcast/multicast lookup service for finding Rinda tuplespaces.</li>
<li><strong>Templates</strong> are used to find tuples to take. <code>Template#match</code> requires that the tuples have the same length, and that all the non-nil elements are triple-equal (<code>===</code>).</li>
<li>In practice arrays are always used in the <code>#take</code> and <code>#write</code> methods, and they’re implicitly converted to the appropriate object.</li>
</ul>
<h2>Protocol design</h2>
<p>When you’re deciding what to store/read in the tuples, you’re essentially designing a communication protocol. So you need to take the extra precautions required as you would when designing any API or protocol, including documentation, evolution of changes, process workflow, etc.</p>
<ul>
<li><em>Parts of tuples:</em> command/request, identifiers, and associated parameters/data. Usually templates will match on the command, sometimes on the ID, but never on the data. </li>
<li>Strings work well in tuples, because you can use Regexps to select them.</li>
<li>Numbers work well, because you can match them with Ranges</li>
<li>Symbols don’t work so well (at least until <a href="http://redhanded.hobix.com/inspect/SymbolIs_aString.html"><code>Symbol < String</code></a>)</li>
<li>Communication patterns -- synchronous communication is not a good fit for a Rinda architecture (e.g., a request for status)</li>
</ul>
<h2>Deployment</h2>
<p>DRb does not marshal code/behavior (unlike Java and RMI). This is a limitation that forces you to consider how to use custom objects in the tuples, because the code must be shared (and thus jointly upgraded) across all participants.</p>
<p>Multiple processes are probably more reliable for the various components of the architecture (RingServer, TupleSpace, clients) rather than using green threads, although this is just a hypothesis.</p>
<p>The TupleSpace is the single point of failure -- if the process with it crashes, when it starts back up, it’s likely to have a new DRb URL, so it’s helpful to have a proxy around the tuple space in clients that can rediscover it if it crashes.</p>
<p>Be wary of multiple ring servers on the same subnet! Behavior may be unexpected. You may notbe using the tuple space that you wanted, and when the other ring server goes away, so does your tuple space.</p>
<p>DRb does not have any security built into it, such as unforgeable object IDs, encrypted transport, authentication, etc. This can be a problem in some situations.</p>
<p>There is no persistence by default, so consider adding some for crash resistance, or deal with occasional loss of tuples.</p>
<p>There are no transactions, so the requester will never know if it still processing or was lost.</p>
<p>As Ruby matures and gains exposure, some libraries that have been good enough for a while may need reconsideration. As a case in point, Rinda and DRb haven’t been updated since February of 2004.</p>
<h2>Q & A</h2>
<p><em>Q. Are write/take atomic?</em> Yes, if you timeout, the tuple will still be there. Two workers cannot get the same tuple.</p>
<p><em>Q. Where would you use this instead of traditional message queues (reinvent the wheel)?</em> There’s more flexibility in this architecture. (Justin Gehtland) In this particular case, they have a JMS backend, but the Ruby code could not assume connectivity to that backend.</p>
<p><em>Q. Is there a common correlator design pattern?</em> Tie response types to request types to limit the pool of potential matches. In the situation where there is a single requester, it’s simple to just generate sequential numbers. In a P2P situation, you may need to use a hostname or PID to help distinguish. [Sounds like a GUID/UUID system to me.]</p>
<p><em>Q. Have you used expiry dates to grab abandoned tuples?</em> No, sounds like an interesting possibility.</p>