[boost] Late asio review

From: Chris Cleeland (cleeland_at_[hidden])
Date: 2006-01-10 23:45:12

Hi,

I'd like to offer the following comments on asio based on 15+ years of 
network programming in various languages and various situations, but as 
somebody who is pretty much a boost novice.  I wish I could become a boost 
expert instantly; my commentary from many previous experiences (some 
successful, and some not) trying to wrap the network programming monster up 
with higher level abstractions.

There are definitely areas that felt "wierd" to me.  Unfortunately, I don't 
know if that is b/c I'm not in tune with "the boost way", or if it's 
something in either the design or the implementation.  In general, I tried to 
ignore those sorts of things.

Regardless, these are the things that really stick out to me:

1. too abstract in places

   Specifically, I'm talking about the whole buffer thing and the hiding of 
   the demuxer's implementation.  I'll address each of these separately:

   (a) buffers: from a certain perspective, this sounds nice, but it 
   seems that there are already so many abstractions over a (void* + 
   length)--do we REALLY need another?  Could this be simplified to something 
   like std::pair<void*, std::size_t> ?

   (b) hiding of demux impl: first, I don't like the fact that it chooses for 
   me at compile time.  Abstraction is nice, but sometimes I, as the 
   programmer, really DO know better or have good reason to choose one thing 
   over another.  Anytime libraries completely force my hand, I rebel.

   In general, I feel that this library throws in enough abstraction to be in 
   the way, but not enough to completely abstract away the features that it's 
   really using.  I don't see how one can get hold of the raw 
   socket descriptor to twiddle options that the library hasn't abstracted.  

   I also know that after 15+ years of network programming, KNOWING the 
   details all the way down to the wire is important for how one writes code.  
   Purists may say that one should never make such assumptions, but the 
   reality is that when your "wire" is gigabit ethernet you get to write code 
   with a certain set of assumption that is completely different from 
   assumptions in place when the "wire" are high-bandwidth/high-latency 
   satellites in geosynch orbit.  The abstractions that are in place in this 
   library seem to insulate me too much.  I would prefer to see a "you don't 
   have to know if you don't want to" philosophy rather than a "you don't 
   need to know because I don't think you need to know" philosophy.

2. unnecessary features

   Is hostname resolution really so much of an overhead that we need 
   asynch hostname resolution?  If the feature were basically "free", I would 
   say okay, but the fact that it requires firing up an extra thread behind 
   the scenes (another one of my pet peeves) makes it seem like a wholly 
   unnecessary feature.

3. header-only implementation

   Besides the fact that this style is "wierd" to me (that's a personal 
   thing), this implementation choice forces users' hands down the line.  
   First, it forces all the code in the "library" to be replicated in every 
   executable.  This is not efficient and increases footprint.

4. How would I implement a timed write with the current async API?  By
   "timed write", I mean that I want to write some hunk of data, but I
   need to know if the write hasn't completed within a certain window
   of time.  This is a common need in performance-sensitive systems,
   and writing it synchronously can be done, but how do I write it
   asynch?

5. TSS and threads

   Shouldn't these rely on boost.thread?  I'm
   especially thinkng of TSS in this case, bceause in ACE/TAO we've
   found that TSS is, at the very least, inconsistent across
   platforms.  See changelog entry in
   ACE_wrappers/Changelogs/ChangeLog-05a for one of t he more
   aggregious examples.

      Wed Feb 16 16:18:45 2005  Dale Wilson  <wilson_d_at_[hidden]>

I look forward to seeing Jeff's consolidation of all the review material and 
what Chris comes up with afterwards!

-- 
  Chris Cleeland, cleeland_c @ ociweb.com, http://www.milodesigns.com/~chris
     Principal Software Engineer, Object Computing, Inc., [phone]
      Support Me Supporting Cancer Survivors in Ride for the Roses 2005
    >>>>>>>>>    Donate at http://www.milodesigns.com/donate    <<<<<<<<<