BIND 10 #1387: timeout on xfrout when sock path too long

[BIND 10 Development]

#1387: timeout on xfrout when sock path too long
-------------------------------------+-------------------------------------
                   Reporter:  jelte  |                 Owner:  jinmei
                       Type:         |                Status:  reviewing
  defect                             |             Milestone:
                   Priority:  major  |  Sprint-20111220
                  Component:         |            Resolution:
  Unclassified                       |             Sensitive:  0
                   Keywords:         |           Sub-Project:  DNS
            Defect Severity:  N/A    |  Estimated Difficulty:  5
Feature Depending on Ticket:  none   |           Total Hours:  1
        Add Hours to Ticket:  0      |
                  Internal?:  0      |
-------------------------------------+-------------------------------------

Comment (by jinmei):

 Replying to [comment:9 jelte]:

 Thanks for the review.

 > Just to be clear, the asio connect() call, when given the optional error
 variable, can still raise exceptions? If so, I wonder if this is also the
 case for some of the other calls then.

 No, if we pass the 'error' parameter, connect() should be exception
 free at the asio level.  Basically, the 'with error' version is a
 wrapper for the throwing version that would look like

 {{{#!c++
 nothrow_func(error& err) {
   try {
     throw_func();
   } catch() {
     convert exception to error code and set it in err;
   }
 }
 }}}

 > xfrout_client.cc:
 >
 > in XfroutClient::connect(), asio::error_code err is now unused and can
 be removed (wonder why neither my compiler nor cppcheck fails on that)

 Ah, good catch, removed.  The reason why the compiler didn't complain
 is this:
 {{{
 AM_CXXFLAGS += -Wno-unused-parameter # see src/lib/cc/Makefile.am
 }}}
 (not sure about cppcheck.  it sometimes overlooks things that it's
 supposed to find)

 In this module, since we only use the quite low level interface (it
 uses send(2) in the end) in the blocking mode, we actually don't need
 the ASIO level abstraction.  So we should probably simply stop using
 asio here, or rather extend asiolink to support unix domain sockets.
 (But that would be a subject of a separate ticket).

 > client_test.cc:
 >
 > My compiler does not allow the uninitialized sockaddr_un structure as a
 const...

 Okay, I think in this case we should simply give up constifying it;
 the brevity would be more important in this context.  I also don't
 think we need to rely on SUN_LEN, which would also have a portability
 issue.

 > BTW, the variable name should also not be sun, as that is a predefined
 macro in sunstudio system headers

 Ah, okay, changed it.

-- 
Ticket URL: <http://bind10.isc.org/ticket/1387#comment:10>
BIND 10 Development <http://bind10.isc.org>
BIND 10 Development