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

[BIND 10 Development]

#801: Design API for requesting/returning/cleaning-up sockets
-------------------------------------+-------------------------------------
                   Reporter:         |                 Owner:  jinmei
  stephen                            |                Status:  reviewing
                       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):

 Replying to [comment:8 vorner]:

 > > 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.
 >
 > So, should I write some or is the description of commands down there
 enough, leaving the exact prototypes for whoever will be implementing
 them?

 To be honest I have no idea as I didn't know what exactly this task
 should do in the first place:-) But it wouldn't make much sense to
 spend too much of time at this level (at the moment maybe the
 important thing is that at least two people consider it), so:

 - Basically, I leave decisions on when to close this ticket to you.
 - I'd provide a couple of actual signatures to show the idea more
   concretely.  Also, code snippet often reveals something we miss.

 > > - what about a raw socket?  DHCP may need it.
 [...]
 > But I didn't work with raw sacket yet, aren't root privileges needed to
 some other manipulation with it?

 I'm not sure if I really understand the question, but if I vaguely
 remember that some systems require the root privilege when sending
 packets via a raw socket (so the application cannot drop the privilege
 after opening the socket).

 > > - 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?
 >
 > What socket options? Calls socket and bind (which are the two
 sockcreator is doing) don't seem to have any parameter to specify options.
 Therefore I think any kind of options can be set later by the application
 by other calls.

 For example, SO_REUSEADDR needs to be set before bind().  And, in the
 case of BIND 9, it sets or unsets this option depending on subtle
 conditions.  We may or may not encounter the same situation, but the
 point is that it's quite likely we'll have some limitation on the
 usage regarding socket options.  This should be clearly documented,
 and we should revisit the point as we have more concrete idea on how
 specifically we use this API.

 I'd also note that if two apps have different policy about whether to
 set a particular socket option, when to set the option is irrelevant.

 > It is true the protocol parameter of socket is hardcoded zero, but is it
 ever used with anything except raw socket? In case of raw socket, there
 wouldn't be bind, but we would pass the protocol instead of the address.

 This is not my point.  What I meant is something like this:

 - Application A wants to have a UDP socket on port 53 with
   SO_REUSEADDR
 - Application B wants to have a UDP socket on port 53 without
   SO_REUSEADDR

 > > - 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've two reasons to do it:
 >  * We might want to secure connection to the msgq sometime in future, so
 other applications that just happen to find the unix socket can't connect
 to the system. The token would provide some level of security and boss
 wouldn't provide low-port sockets to just anybody (I heard that on some
 systems, the permissions on the socket file aren't taken into account).
 >  * Passing data structures (like the parameters of the socket and
 parameters of sharing) through the msgq is simpler than encoding them
 manually to the socket.

 I don't object to that, but these rationales should be documented, and
 it should be based on a fact, not a rumor (i.e., not only say "I heard
 X...", but we say "ABC OS doesn't take into count xxx").

 > > - 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.
 >
 > Well, in that case user would provide different addresses to listen on
 and they would get different sockets without any problem (the sharing
 would be, of course, only with sockets bound to same addresses). I was
 more worried about someone specifying both auth and resolver listening on
 0.0.0.0:53, which is what people would want and it seems logic, it just
 wouldn't work. Having internal and external auth both listening on
 everything makes no sense from the administrator point of view.

 My example was certainly inspired by views, but my point was more
 generic.  What I wanted to point out is that the definition of "same
 kind" may not be so obvious, and since full generality wouldn't make
 sense or would be too difficult to implement, we'll have to make some
 restriction/compromise.  So we have to give our own definition of
 "same kind", and explain restrictions due to that.

 Besides, it's actually not so uncommon that two views listen on the
 same address/port: they behave differently based on the "from
 address".

 > > - s/IP/IPv4/ ("IP" would mean a different version in a few years:-)
 >
 > Fixed, but I hope this document will be obsolete by then and the
 sockcreator implemented ;-)

 Maybe you forgot to push?  The branch doesn't seem to be updated.  The
 other typo wasn't fixed either.

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