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-20130423
           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
-------------------------------------+-------------------------------------
Changes (by vorner):

 * owner:  vorner => jinmei


Comment:

 Hello

 Replying to [comment:17 jinmei]:
 > Do you have a reference for that behavior?  In my understanding
 > connect() returns as long as the other end has listen()ed on it (and
 > if the remote end doesn't even listen(), connect() immediately fails
 > due to ECONNRESET).  At least that's how implementations of TCP as
 > described in RFC793 work, and from a quick experiment that's the same
 > for UNIX domain stream sockets.  In the case of real TCP, connect()
 > can certainly block because the SYN or SYN-ACK packet may be lost, but
 > that's not the case for the UNIX domain protocol.

 I'm probably still unifying UNIX/STREAM with TCP in my head. And it looks
 strange to consider the connection created even in case accept() was not
 called yet, but if the API really does that, OK.

 I tried to define the difference between „non-blocking“ operation and
 „fast“ operation somehow. I hope it clarifies it.

 > '''Definitions/message'''
 > - the difference may be subtle, but to be very precise I think
 >   recipients of a message are "the system itself, a session of some
 >   (normally different) user, or a set of sessions (called a group,
 >   see below, which is possibly empty)", that is, they are generally
 >   "sessions", not "users", even if at the application level the
 >   intended recipient is the user of the session(s).  Same for "The
 >   session/Send", "Assumptions", etc.

 ACK.

 > - Opening a session: I'd like to clarify how long the "short amount of
 >   time" is.  My understanding of the assumption is that making a
 >   connection is essentially done in an instant, and getting the
 >   session ID is also done without a delay (the session is initially
 >   empty and should never block and the system responds to the request
 >   immediately).  With these assumptions, it should be okay, for
 >   example, to open a new session in the middle of handling an
 >   interactive session (e.g, handling a human user's request) while it
 >   may still be considered heavy weight for doing many times per second
 >   (e.g., open a new session every time a DNS server receive a query).

 I think the definition of fast should describe it now.

 > - Send: this description is quite open about whether a user needs to
 >   expect blocking on send.  I'd say either the user can assume it's
 >   non blocking (which would be ensured not only by OS level but
 >   also, e.g., with a library level buffer) or it should use some
 >   asynchronous interface if it cannot accept blocking.

 The user should expect non-blocking. I still left the note that this is
 based on an assumption.

 > - it's not clear to me how a user shows the "interest" on a group or
 >   session.

 I described it is by subscribing to a group. Then, the unsubscribtion
 should follow from that, even if it is not mentioned explicitly.

 > - This note seems to be implementation details rather than high level
 >   property:
 > {{{
 > Note that in early stages of startup (before the configuration
 > manager's session is opened), the `Msgq` alias is not yet available.
 > }}}
 >   I was not sure how this note matters at this level; if it doesn't, I'd
 >   remove the note to avoid the confusion.  If it does, I'd describe
 >   the specific issue, and also generalize the description without the
 >   concept of "configuration manager", e.g., "In the actual
 >   implementation there can be a time lag before the 'Msgq' alias is
 >   available for other users even when other users can open a session
 >   to the system.  So, ...??? (I don't know so what)".

 I tried to clarify it. I think it might be useful for someone reading or
 modifying some base module, like the cfgmgr itself. I also noted the
 „usual“ module doesn't need to worry about it.

 >   in that "msgq" (which is an alias isn't it?) is used as the sender
 >   (which I thought was expected to specify a session ID).

 Explained. Actually, it is an lname, but a special one in some sense.

 Generally, clients don't need to care about that, since they don't examine
 the sender on answers. But the msgq needs to put there something (and it
 might not have real lname yet).

 > - I'd describe what users would do, just like "the system" section.

 I described some usual behaviour. But I don't know what properties or such
 to describe on clients, as they are the users of the API, they have
 freedom to do whatever they like.

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