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


Comment:

 Hello

 Replying to [comment:9 jinmei]:
 > - 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.

 I added a snippet that shows it somehow, I hope it will be clear about the
 idea how to use it and the exact details can be left for the
 implementator.

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

 Yes, that was exactly my concern ‒ if it needs root privileges to do
 anything useful with it (like send packets), it can as well just create
 the socket itself and not bother itself with asking some other component
 to do it. Well, let's wait and see if they are needed.

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

 Hmm, crap, I didn't know about these. Well, let's leave them out for now
 (we don't use them now) and hope they won't be needed. If they are, we
 will have to extend it later.

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

 In case of SO_REUSEADDR yes, but in case of blocking/nonblocking, it is
 set on the one single copy of socket (I guess sending a socket trough the
 connection acts similar as dup in 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

 Hopefully these would be different application that wouldn't be willing to
 share the socket with each other and the problem would solve out itself
 anyway. But let's worry about that if we have the options.

 > 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 documented the rationale and I found a link hinting what I said, that
 some OSes do ignore the permissions, but it still isn't authoritative
 source of information and doesn't say which OSes they are. But that's a
 minor point in the rationale anyway, so I hope it isn't so much of a
 problem.

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

 Well, then they either could not be in different processes (therefore
 there would be no need to share it) or they couldn't share it (because the
 packet could end up in the wrong application). We will need to solve this
 problem somehow when we get to it, possibly by the receptionist or
 something like that.

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

 I did, I pushed now.

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