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