{"id":153,"date":"2008-03-04T22:33:49","date_gmt":"2008-03-05T02:33:49","guid":{"rendered":"http:\/\/mattwork.potsdam.edu\/blog\/2008\/03\/04\/back-to-billboarding\/"},"modified":"2012-11-12T09:03:29","modified_gmt":"2012-11-12T14:03:29","slug":"back-to-billboarding","status":"publish","type":"post","link":"http:\/\/www.matthewgkeller.com\/blog\/2008\/03\/04\/back-to-billboarding\/","title":{"rendered":"Back to Billboarding"},"content":{"rendered":"<p>Billboarding used to be <em>the<\/em> way to share groups of read-heavy bit or small-byte data across numerous processes or systems. The concept was simple: Have a file with a bunch of zeros in it, and on occasion change one of the zeros to a one. Processes\/systems reading that file would say &#8220;Hmmm, the 4th &#8216;slot&#8217; is now a &#8216;1&#8217;, and that means [thing]&#8221;. This was used for everything from node status, to process states, to primitive anticipatory scheduling. Then objects became popular. Why read out of a billboard, when you can just share flag data across objects?<\/p>\n<p>Well they&#8217;re back, it seems. Billboards have made a small-yet-noticeable resurgence in a number of systemic regions, and more than a couple system architects have noticed clients requesting solutions that boil down to billboarding (although generally given a more sexy name like &#8220;shared state file&#8221; or &#8220;offline node graph&#8221;).<\/p>\n<p>I&#8217;ve had two projects in the last 6 months that have required, in general, a billboard, and am very happy to see them come back into vogue. They&#8217;ve been &#8220;gone&#8221; long enough so that the cool kids think they&#8217;re brilliant and &#8220;out-of-the-box&#8221; when they propose the &#8220;radical concept&#8221; of the &#8220;shared state file&#8221;, and those of us who&#8217;ve been doing advanced system architecture for .. gasp .. almost 15 years now, just smile and jot &#8220;billboard&#8221; in our notepad.<\/p>\n<p><strong>Systemic Billboards <\/strong><\/p>\n<p>In environments where there is shared (and preferably clustered) storage, billboards make a ton of sense as a means of easily communicating with other nodes. More than just 0&#8217;s and 1&#8217;s, a node can communicate an array of information about its health &#8211; and also other nodes can ask other nodes to do something. Maybe setting a node state to &#8216;2&#8217; means &#8220;please restart your user services&#8221; or &#8216;3&#8217; means &#8220;please reboot&#8221;. Whenever a node reads its own entry it can go &#8220;Hey cool, I&#8217;m suppose to do something.&#8221; As a means of pre-failure fencing, this is exceptionally handy as one does not necessarily have a connection to a greater network, but still may have a connection to storage- Allowing a control system to tell others &#8220;Hey, something bad is happening, please shut down&#8221;, for example if one node detects a UPS failure or pending drainage.<\/p>\n<p>I currently have a project that requires the assumption that if bad things happen, the only communication available between nodes will be a shared IEEE1394 drive array &#8211; A better place to use a billboard does not exist.<\/p>\n<p><strong>Non-Systemic, or Quasi-Systemic Billboards\u00c2\u00a0<\/strong><\/p>\n<p>Given an application that may have any number of processes (for example, any web-based application), using a billboard as a light IPC for each process to communicate its state or intentions, can save a lot of otherwise tricksy IPC coding. Sure, you can have a pipe dangling out there- But what happens if a process needs to skip a pipe read for a given cycle, and in the mean time the status of the pipe changes? Yes, you could have one pipe per process, but then you&#8217;re looking at a mess that could be more elegantly solved with &#8230; a billboard. With 256 ASCII characters available (I&#8217;m not even going to get into the possibilities with Unicode), you can communicate up to 255 different things per process&#8211; all sitting happily waiting to be read whenever is convenient, or necessary, with very very little side-effect.<\/p>\n<p>Yes, contention issues need to be addressed by your application.<\/p>\n<p>Yes, if your application is poorly designed and process spawn rates are out-of-control, a billboard will destroy your performance.<\/p>\n<p>Yes, if your storage disappears, there is a problem: A big problem that a web application cannot solve, so its inability to get to the billboard could definitely be a sign that maybe it should go into a maintenance state instead of processing transaction it can&#8217;t actually handle.<\/p>\n<p>Yes, if the file becomes corrupted, Bad Things could happen: The application can\/should detect such problems and Do The Right Thing.<\/p>\n<p>There are certainly situations where billboards are not the answer. There are certainly situations where using IPC or nodal communication is a better solution. I&#8217;ve never advocated billboards as the end-all of inter-process or inter-nodal communication: Only that it shouldn&#8217;t be discounted in cases it DOES make sense.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Billboarding used to be the way to share groups of read-heavy bit or small-byte data across numerous processes or systems. The concept was simple: Have a file with a bunch of zeros in it, and on occasion change one of &hellip; <a href=\"http:\/\/www.matthewgkeller.com\/blog\/2008\/03\/04\/back-to-billboarding\/\">Continue reading <span class=\"meta-nav\">&rarr;<\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[4,10],"tags":[],"class_list":["post-153","post","type-post","status-publish","format-standard","hentry","category-architecture","category-linuxy"],"_links":{"self":[{"href":"http:\/\/www.matthewgkeller.com\/blog\/wp-json\/wp\/v2\/posts\/153","targetHints":{"allow":["GET"]}}],"collection":[{"href":"http:\/\/www.matthewgkeller.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"http:\/\/www.matthewgkeller.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"http:\/\/www.matthewgkeller.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"http:\/\/www.matthewgkeller.com\/blog\/wp-json\/wp\/v2\/comments?post=153"}],"version-history":[{"count":0,"href":"http:\/\/www.matthewgkeller.com\/blog\/wp-json\/wp\/v2\/posts\/153\/revisions"}],"wp:attachment":[{"href":"http:\/\/www.matthewgkeller.com\/blog\/wp-json\/wp\/v2\/media?parent=153"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"http:\/\/www.matthewgkeller.com\/blog\/wp-json\/wp\/v2\/categories?post=153"},{"taxonomy":"post_tag","embeddable":true,"href":"http:\/\/www.matthewgkeller.com\/blog\/wp-json\/wp\/v2\/tags?post=153"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}