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

 * owner:  vorner => jinmei
 * status:  assigned => reviewing


Comment:

 Hello

 Replying to [comment:6 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.

 So, should I write some or is the description of commands down there
 enough, leaving the exact prototypes for whoever will be implementing
 them?

 > - what about a raw socket?  DHCP may need it.

 I didn't think of it, when I start sockcreator, we didn't have DHCP. But
 it should be quite simple to add raw socket to it and to the protocol.

 But I didn't work with raw sacket yet, aren't root privileges needed to
 some other manipulation with 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?

 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.

 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.

 > - 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.

 In this sense it is similar to FTP, the control and data connection.

 I'd really like to pass the results through the msgq too, but it doesn't
 seem easy.

 > - 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).

 Well, that's the option one of caching of sockets. Or, more or less it, I
 think it is better done in the msgq than boss, since it has direct access
 to the sockets to them and can see things others can't (errors/full write
 queues/connection resets). And, as I noted, dbus does it already, so it
 was the reason I wanted to have the msgq replacement (if any) before we
 start implementing sockcreator.

 > - 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.

 Anyway, wouldn't such internal/external better be done by ACLs?

 And, I guess your example assumes some kind of views in place. We didn't
 yet talk too much how such thing would look like. Maybe in that case the
 name of application would be the name of the view?

 > - 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 ;-)

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