BIND 10 #2738: Clarify high-level design of the CC protocol

[BIND 10 Development]

#2738: Clarify high-level design of the CC protocol
-------------------------------------+-------------------------------------
            Reporter:  vorner        |                        Owner:
                Type:  task          |  jinmei
            Priority:  medium        |                       Status:
           Component:  Inter-module  |  reviewing
  communication                      |                    Milestone:
            Keywords:                |  Sprint-20130402
           Sensitive:  0             |                   Resolution:
         Sub-Project:  DNS           |                 CVSS Scoring:
Estimated Difficulty:  5             |              Defect Severity:  N/A
         Total Hours:  0             |  Feature Depending on Ticket:
                                     |          Add Hours to Ticket:  0
                                     |                    Internal?:  0
-------------------------------------+-------------------------------------

Comment (by jinmei):

 - I think the high level design should use a higher level abstraction
   of message "bus" (or "system" or whatever), and should be described
   without the concept of msgq (which is just a specific implementation
   of the bus).

 - I'd like to clarify the response (answer) semantics for broadcasting
   (i.e. "addressing by group").  If we expect it to work in some way,
   we should describe how it should work in more detail.  But, from
   what I've read from this document, I guess an implicit assumption is
   that we actually didn't expect it to work; if the sender needs a
   response to the same single message from multiple recipients, it
   should first get a list of individual recipients and send a direct
   message to each of them.  I'm okay with that model, but then I
   suggest explicitly prohibiting (or at least discouraging, saying
   "the behavior is undefined and you shouldn't do it) broadcasting
   with expecting an answer(s).

 - I also like to clarify that read/write should never "fail" (here,
   getting no answer is not considered a failure) and, if that ever
   happens the module should consider it fatal and terminate.

 - I'd also like to clarify whether the sender needs to expect blocking
   on write.  As we discussed before, IMO we should ensure it's non
   blocking at the lower level (and it seems to be not so difficult at
   least for the C++ API).

 - "Undeliverable notification": I guess we should revisit this concept
   at a higher level, while I see it addresses some real issues due to
   our current implementation details.  First, it only matters when the
   sender requests an answer.  And, since an answer can be delayed due
   to a reason at the recipient side, which the sender cannot control,
   if the sender cannot do blocking wait for the answer it must wait
   for it asynchronously anyway; in the case the sender can do blocking
   wait, it might be a good optimization to tell the sender the failure
   sooner, but it seems to be a implementation-specific bonus feature,
   rather than a matter of higher level design.  So my personal
   suggestion is to remove it from this high level design (or if we
   mention it, clarify it's an implementation level optimization and
   modules that can't block should need asynchronous read anyway).

 - I'm not sure about what this means:
 {{{
   * Client with given lname connected
 }}}
   lname is not known until the client is actually connected to the bus,
   so I don't understand how to "give" the lame of the client for the
   notification.  Or, does this mean the event of "a client is connected
   to the bus (or the "system")" (and the notification includes the lname
   of the client)?

 - Likewise, the usage of this is also a bit unclear:
 {{{
   * Client with given lname subscribed to given group
 }}}
   Does this mean the event of "a client subscribes to a given group"
   (and the notification includes the lname of the client)?

 - what specifically does "members" mean hear?  list of subscriber
   lnames of a given group?  what's the "list of all connections"?
 {{{
 List of group members:
   The MSGQ provides a command to list members of given group and list
   of all connections.
 }}}

  "NOTE" of Event notifications: I simply couldn't understand these
  three paragraphs very well (so it's even difficult to say specifically
  what's the problem beyond "I didn't understand it").  Maybe the first
  paragraph should be more detailed, clarifying what's state and race
  mean, and maybe revising the examples with something better.

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