[click] paper help

[Douglas S. J. De Couto]

We are using Click as the software infrastructure for the Grid ad hoc
routing protocol.  

There are two main kinds of advantages: implementation details, and
unique Click-specific benefits.

Implementation benefits (no particular order):

1) nice build system, no screwing around with makefiles.   the ability
   to do click-mkmindriver.  of course, we wouldn't need this if click
   didn't include the kitchen sink...

2) ``self''-documenting.  the ability to extract man pages from
   element source is really cool, and encourages you to keep comments
   up to date.  i even use the man pages for my own elements...

3) userlevel.  this aids debugging.  it also makes it more portable.
   we have on set of code that has run on FreeBSD, OpenBSD, Linux,
   i386, ipaqs, etc.  a key benefit of userlevel is that you can
   create multiple ``virtual'' routers in a network by coding up the
   appropriate perl script and config file.  this is useful for
   testing: nothing has to actually run connected to the real world.
   Even if your final protocol deployment runs in the kernel, you can
   still use the userlevel testing...

4) relatively rich c++ library (strings, vector, map, etc).  it's too
   bad it doesn't use the standard c++ library... oh well.



Unique Click benefits (no particular order):

1) elements are great.  they are a really cool concrete realization of
   modularity.  when you split your protocol into elements (even if
   they are probably not quite the right breakdown for the specific
   protocol), you get a unit of code that is easier to compile and
   test.  Also, it somehow makes it easier to be incremental about
   changes.  i can't put my finger on it though...

2) Having a configuration language is great.  You can change your
   protocol without programming.  Also, many kinds of bugs happen at a
   level that can be fixed without recompilation.  These are mostly
   bugs from bad constants, like classifier offsets and patterns.
   Although it may be true that some of these bugs *come from*
   splitting the configuration/hookup from the C++ level (which knows
   about sizes and offsets) -- this is not an issue if you are using
   predefined protocols like IP etc. which have a rich set of
   elements with lots of protocol knowledge coded into them
   (IPCLassifier for example).

   The configuration is great for debugging.  i.e. Print
   debuggin... you can add print statements to trace packet flow and
   contents without recompiling any code.  Bonus!

3) We use the predefined els for IP and ICMP processing, IP
   classifications, ARP, and NAT functions.  Double Bonus!

4) The easy-to-use control mechanisms.  ControlSocket/ChatterSocket
   (plus chatter channels) let you expose cool protocol stuff to the
   application with no kernel / system call hacking.  This makes it
   easier to prototype the protocol/application interface with low
   overhead. e.g. we have adding a Grid traceroute protocol,
   geocasting, and application access to routing tables and other
   protocol data structures.



I probably forgot some other really useful stuff.

cheers,

d
-- 
Douglas S. J. De Couto    decouto at lcs.mit.edu