<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
   <channel>
     <atom:link href="http://www.omninerd.com/feeds/rss" rel="self" type="application/rss+xml" />
      <title>brho on OmniNerd</title>
      <link>http://www.omninerd.com</link>
      <description>All of the latest articles, news, blogs and comments from brho on OmniNerd.com</description>
      <language>en-us</language>
      <pubDate>Mon, 20 May 2013 02:09:35 -0500</pubDate>
      <lastBuildDate>Mon, 20 May 2013 02:09:35 -0500</lastBuildDate>
      <docs>http://blogs.law.harvard.edu/tech/rss</docs>
      <generator>OmniNerd Feed Generator</generator>
      <managingEditor>mark@omninerd.com (Mark McBride)</managingEditor>
      <webMaster>mark@omninerd.com (Mark McBride)</webMaster>
      <item>
         <title>Who Wants to Fight Cybersquatters for About $500? - Article</title>
         <link>http://www.omninerd.com/articles/Who_Wants_to_Fight_Cybersquatters_for_About_500</link>
         <guid isPermaLink="true">http://www.omninerd.com/articles/Who_Wants_to_Fight_Cybersquatters_for_About_500</guid>
         <description>
         <p>Just the other day a friend of mine had a nice idea for a website, and like many descriptive names, the <a href="http://www.scripthub.com/">website</a> was taken.  It&#8217;s one of those fake looking websites with some ads links, and of course a <a href="http://www.scripthub.cominquiry.html?Query=2USvGqi1seRhgZIwjZItjsA2sQEDOGSmrnA%2F">page</a> where you can submit an offer to buy the site for an excessive amount of money.  Wouldn&#8217;t it be nice if we could use the legal system to deal with this?</p>This article  continues, read the rest on <a href="http://www.omninerd.com/articles/Who_Wants_to_Fight_Cybersquatters_for_About_500">OmniNerd</a>.<br/>
         
         <br/><a href="/comments/new?content_id=4021&amp;content_type=Article#comment_form_header">Add a Comment (15)</a>         </description>
         <author>brho</author>
         <pubDate>Mon, 14 Nov 2011 15:50:36 -0800</pubDate>
            <category>cybersquatting</category>
            <category>websites</category>
            <category>udrp</category>
            <category>grad student rants</category>
            <category>domain names</category>
      </item>
      <item>
         <title>Installing GRUB on a Hard Disk Image File - Article</title>
         <link>http://www.omninerd.com/articles/Installing_GRUB_on_a_Hard_Disk_Image_File</link>
         <guid isPermaLink="true">http://www.omninerd.com/articles/Installing_GRUB_on_a_Hard_Disk_Image_File</guid>
         <description>
         <h2>Introduction</h2>
<p><a href="http://www.gnu.org/software/grub/"><span class="caps">GRUB</span></a> is the GRand Unified Bootloader.  For those unfamiliar, a bootloader is a critical piece of software used when a computer turns on.  Its job is to load an operating system.  The bootloader resides on a disk of some sort (floppy, hard) and is called by the <span class="caps">BIOS</span>, which is the real low-level program that runs on startup.  <span class="caps">GRUB</span> is installed at a specific location on these devices.</p>This article  continues, read the rest on <a href="http://www.omninerd.com/articles/Installing_GRUB_on_a_Hard_Disk_Image_File">OmniNerd</a>.<br/>
         
         <br/><a href="/comments/new?content_id=2373&amp;content_type=Article#comment_form_header">Add a Comment (15)</a>         </description>
         <author>brho</author>
         <pubDate>Sat, 24 Jan 2009 11:58:42 -0800</pubDate>
            <category>grub</category>
            <category>virtualization</category>
            <category>computers</category>
            <category>disk images</category>
      </item>
      <item>
         <title>Multicast - Article</title>
         <link>http://www.omninerd.com/articles/Multicast</link>
         <guid isPermaLink="true">http://www.omninerd.com/articles/Multicast</guid>
         <description>
         <p>A Reliable Multicast Framework for Light-weight Sessions and Application Layer Framing<br />
<del>-</del><del>-</del><del>-</del><del>-</del><del>-</del><del>-</del><del>-</del><del>-</del><del>-</del><br />
This is an attempt to build a general reliable multicast implementation on top of IP multicast.  It attempts to leave many of the decisions to the application layer (in accordance with the E2E principle) and provide only the basics all MC implementations need.  It&#8217;s fundamental flaw is that it relies on IP multicast, which no one uses.</p>This article  continues, read the rest on <a href="http://www.omninerd.com/articles/Multicast">OmniNerd</a>.<br/>
         
         <br/><a href="/comments/new?content_id=2300&amp;content_type=Article#comment_form_header">Add a Comment (0)</a>         </description>
         <author>brho</author>
         <pubDate>Thu, 20 Nov 2008 10:07:24 -0800</pubDate>
            <category>networking</category>
            <category>multicast</category>
            <category>cdn</category>
      </item>
      <item>
         <title>Delay-Tolerant and Data-Oriented Networks - Article</title>
         <link>http://www.omninerd.com/articles/Delay_Tolerant_and_Data_Oriented_Networks</link>
         <guid isPermaLink="true">http://www.omninerd.com/articles/Delay_Tolerant_and_Data_Oriented_Networks</guid>
         <description>
         <p>A Delay-Tolerant Network Architecture for Challenged Internets (<span class="caps">DTN</span>)<br />
<del>-</del><del>-</del><del>-</del><del>-</del><del>-</del><del>-</del><del>-</del><del>-</del>&#8212;&#8212;<br />
Not all networks look like the Internet.  Our current network stack is built on the assumptions: an end-to-end path exists, it has reasonable RTTs, and packets will arrive with reasonably high probability.  These assumptions do not hold for may interesting networks, such as satellite networks, ad-hoc networks, sensor networks, poor-people networks, etc.  One interesting network they use is a vehicle, like a bus, that drives from A to B.  It physically moves packets around, and when a node is in range of the bus, it can send a load of packets to be delivered to the other end &#8211; very much like the postal service.</p>This article  continues, read the rest on <a href="http://www.omninerd.com/articles/Delay_Tolerant_and_Data_Oriented_Networks">OmniNerd</a>.<br/>
         
         <br/><a href="/comments/new?content_id=2296&amp;content_type=Article#comment_form_header">Add a Comment (0)</a>         </description>
         <author>brho</author>
         <pubDate>Tue, 18 Nov 2008 12:05:51 -0800</pubDate>
            <category>networking</category>
            <category>dtn</category>
      </item>
      <item>
         <title>Measurement and Tracing - Article</title>
         <link>http://www.omninerd.com/articles/Measurement_and_Tracing</link>
         <guid isPermaLink="true">http://www.omninerd.com/articles/Measurement_and_Tracing</guid>
         <description>
         <p>End-to-End Internet Packet Dynamics<br />
<del>-</del><del>-</del><del>-</del><del>-</del><del>-</del><del>-</del><del>-</del><del>-</del><del>-</del><del>-</del><del>-</del>&#8212;<br />
This is one of those measurement papers that bridge the gap between facts and intuition.  It was done in 1995, and consisted of <span class="caps">TCP</span> communications between 35 sites.  Initially, the paper started out a little dry and boring, but has a lot of interesting results.</p>
<p>Some highlights: <br />
- Out of order packet delivery is not that big of a deal, possibly because our current fast retransmit threshold for dups is conservative.  More research is required to know if these values should be tuned.</p>This article  continues, read the rest on <a href="http://www.omninerd.com/articles/Measurement_and_Tracing">OmniNerd</a>.<br/>
         
         <br/><a href="/comments/new?content_id=2294&amp;content_type=Article#comment_form_header">Add a Comment (2)</a>         </description>
         <author>brho</author>
         <pubDate>Thu, 13 Nov 2008 08:09:43 -0800</pubDate>
      </item>
      <item>
         <title>Naming and Overlay Architectures - Article</title>
         <link>http://www.omninerd.com/articles/Naming_and_Overlay_Architectures</link>
         <guid isPermaLink="true">http://www.omninerd.com/articles/Naming_and_Overlay_Architectures</guid>
         <description>
         <p><strong><a href="http://www.cs.berkeley.edu/%7Erandy/Courses/CS268.F08/papers/33_doa-osdi04.pdf">Middleboxes No Longer Considered Harmful</a></strong><br />
Middleboxes are things like <span class="caps">NAT</span> boxes or firewalls.  They violate basic tenets of the Internet, specifically that every node is uniquely identified and that network devices should not process packets.  This paper presents and architecture (<span class="caps">DOA</span> &#8211; Delegation-Oriented Architecture) to enable the use of these middle boxes in a way that does not violate these tenets.</p>
<p>The main idea is to decouple the IP address from the host ID, called the <span class="caps">EID</span> (endpoint ID).  The <span class="caps">EID</span> is independent of network topology.  IPv6 is another approach to uniquely identifying an endpoint, but it is not independent from the topology.  The authors downplayed the benefit of IPv6; it does get rid of the need for <span class="caps">NAT</span>-style middleboxes.  Still, there are other things such as mobility that benefit from DOA&#8217;s location-independence that IPv6 lacks.</p>This article  continues, read the rest on <a href="http://www.omninerd.com/articles/Naming_and_Overlay_Architectures">OmniNerd</a>.<br/>
         
         <br/><a href="/comments/new?content_id=2288&amp;content_type=Article#comment_form_header">Add a Comment (3)</a>         </description>
         <author>brho</author>
         <pubDate>Thu, 06 Nov 2008 08:12:22 -0800</pubDate>
      </item>
      <item>
         <title>DNS and the Web - Article</title>
         <link>http://www.omninerd.com/articles/DNS_and_the_Web</link>
         <guid isPermaLink="true">http://www.omninerd.com/articles/DNS_and_the_Web</guid>
         <description>
         <p><strong><a href="http://bnrg.eecs.berkeley.edu/~randy/Courses/CS268.F08/papers/31_dns.pdf">Development of the Domain Name System</a></strong><br />
This paper discusses the issues and motivations for the design of <span class="caps">DNS</span>.  The main ideas are hierarchies and caching.  The old way was to use a centralized text file (<span class="caps">HOSTS</span>.<span class="caps">TXT</span>), but this was in violation of one of the principles of the Internet &#8211; distributed management.  Plus, the system was slow to respond and did not scale.  <span class="caps">DNS</span> is about partitioning the name-space database, and it made sense to do so across the same organizational boundaries that make up the internet.</p>This article  continues, read the rest on <a href="http://www.omninerd.com/articles/DNS_and_the_Web">OmniNerd</a>.<br/>
         
         <br/><a href="/comments/new?content_id=2286&amp;content_type=Article#comment_form_header">Add a Comment (5)</a>         </description>
         <author>brho</author>
         <pubDate>Tue, 04 Nov 2008 08:04:34 -0800</pubDate>
            <category>dns</category>
            <category>networking</category>
            <category>internet</category>
      </item>
      <item>
         <title>Distributed Hash Tables - Article</title>
         <link>http://www.omninerd.com/articles/Distributed_Hash_Tables</link>
         <guid isPermaLink="true">http://www.omninerd.com/articles/Distributed_Hash_Tables</guid>
         <description>
         <p><strong><a href="http://bnrg.eecs.berkeley.edu/~randy/Courses/CS268.F08/papers/30_p12-stoica.pdf">Chord: A Scalable P2P Lookup Service for Internet Applications</a></strong><br />
Chord is a distributed lookup service that maps keys on to nodes.  It&#8217;s sole purpose is to perform a lookup function.  Its benefits are that each node only needs to know about a subset of the total nodes to route queries, perform lookups, etc, which enhances its scalability.</p>
<p>Some specifics: it uses a ring logical topology to perform the mapping of keys to nodes with the assumption that keys will map to whatever node has the same or greater value as the keys value on the ring.  It uses exponential/logarithmic algorithms to determine which nodes each node is aware of, which helps bound lookup and recovery time to log(n) or log^2(n).  This subset of nodes a given node is aware of is stored in a &quot;finger&quot; table, of which the direct successor is the first finger.  Check out Figure 3 or draw a picture with exponentially spaced neighbors.  One other thing to consider is that these algorithms often give the ID of the next node.  If there isn&#8217;t a node at that exact point, you round to the next node.  It is possible that one node might appear as several successive finger entries.</p>This article  continues, read the rest on <a href="http://www.omninerd.com/articles/Distributed_Hash_Tables">OmniNerd</a>.<br/>
         
         <br/><a href="/comments/new?content_id=2283&amp;content_type=Article#comment_form_header">Add a Comment (0)</a>         </description>
         <author>brho</author>
         <pubDate>Thu, 30 Oct 2008 08:54:51 -0700</pubDate>
            <category>chord</category>
            <category>dhts</category>
            <category>p2p</category>
      </item>
      <item>
         <title>Overlay Networks - Article</title>
         <link>http://www.omninerd.com/articles/Overlay_Networks</link>
         <guid isPermaLink="true">http://www.omninerd.com/articles/Overlay_Networks</guid>
         <description>
         <p><strong><a href="http://bnrg.eecs.berkeley.edu/~randy/Courses/CS268.F08/papers/27_ron-sosp2001.pdf">Resilient Overlay Networks</a></strong><br />
RONs are small scale, application-centric networks that ride over IP that improve redundancy and performance for their applications.  They are really impressive.  Their main improvement comes from their small scale, which is also their main limitation.  <span class="caps">BGP</span> is designed to scale well; it dampens route changes to prevent oscillations and hides many topoligical details so that the large-scale algorithms can complete.  RONs typically involve far fewer nodes, and they are capable of using link-state routing algorithms to determine the best paths to take.</p>This article  continues, read the rest on <a href="http://www.omninerd.com/articles/Overlay_Networks">OmniNerd</a>.<br/>
         
         <br/><a href="/comments/new?content_id=2282&amp;content_type=Article#comment_form_header">Add a Comment (2)</a>         </description>
         <author>brho</author>
         <pubDate>Tue, 28 Oct 2008 09:05:24 -0700</pubDate>
      </item>
      <item>
         <title>More Internet Topology - Article</title>
         <link>http://www.omninerd.com/articles/More_Internet_Topology</link>
         <guid isPermaLink="true">http://www.omninerd.com/articles/More_Internet_Topology</guid>
         <description>
         <p>On Power-Law Relationships of the Internet Topology<br />
<del>-</del><del>-</del><del>-</del><del>-</del><del>-</del><del>-</del><del>-</del><del>-</del>-<br />
First &#8211; read up on Power laws (Wikipedia).  They basically are scale invariant relationships that can be used to express meaningful things in the long tail of the distribution.  This is where the &quot;interesting&quot; things happen, esp in the Internet&#8217;s topology.</p>
<p>This paper was about using power laws to describe the topology of the internet.  They present a few of these rules that they insist will remain somewhat fixed over the development of the Internet &#8211; barring any major technological change.  These rules link features such as the degree of a node to the number of nodes with that rank.</p>This article  continues, read the rest on <a href="http://www.omninerd.com/articles/More_Internet_Topology">OmniNerd</a>.<br/>
         
         <br/><a href="/comments/new?content_id=2278&amp;content_type=Article#comment_form_header">Add a Comment (1)</a>         </description>
         <author>brho</author>
         <pubDate>Tue, 21 Oct 2008 09:13:05 -0700</pubDate>
      </item>
   </channel>
</rss>
