BIND 10 #801: Design API for requesting/returning/cleaning-up sockets

BIND 10 Development do-not-reply at isc.org
Fri Aug 5 17:52:52 UTC 2011


#801: Design API for requesting/returning/cleaning-up sockets
-------------------------------------+-------------------------------------
                   Reporter:         |                 Owner:  jinmei
  stephen                            |                Status:  accepted
                       Type:         |             Milestone:
  enhancement                        |  Sprint-20110816
                   Priority:  major  |            Resolution:
                  Component:  Boss   |             Sensitive:  0
  of BIND                            |           Sub-Project:  Core
                   Keywords:         |  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 don't know which level of "API" is expected here either.  I'd
 normally expect something like function signatures (even if it's only
 for a preliminary reference rather than a fixed proposal) by that
 term, but maybe it's intended to be deferred to some subsequent tasks.

 '''Random comments for the design'''

 - what about a raw socket?  DHCP may need it.
 - what about socket options?  how/whether can an application specify a
   socket option?  what if two applications request sockets with
   different option settings but with the same port and protocol?
 - I'm not sure if the boss and other apps need to pre-negotiate it via
   the command channel (not to say it's a bad idea though).  Especially
   if they keep open a separate channel to exchange FDs, I guess they
   could do everything on it.
 - I see it would be a difficult problem to keep track of whether
   specific apps are active.  And I think we should consider it as a
   general issue, possibly as part of the msgq replacement project
   (e.g. boss and others may have to run some keep-alive protocol).
 - I suspect that the definition of same/different kind of applications
   is not that trivial.  For example, we may run two auth processes,
   one for "internal", and the other for "external", and these two
   would listen on different addresses.  In this case the corresponding
   sockets shouldn't be shared by the two processes.  But I have no
   concrete idea of how to cleanly solve this.  We should probably make
   some compromise, and the result may be the simplest same/different
   kinds such as just the program name in the end.

 '''typo/editorial'''

 - s/IP/IPv4/ ("IP" would mean a different version in a few years:-)
 - s/at last/at least/

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


More information about the bind10-tickets mailing list