Replacing inndstart
Russ Allbery
rra at stanford.edu
Sun Dec 29 01:52:47 UTC 2002
Russ Allbery <rra at Stanford.EDU> writes:
> Here's my latest toy. This is probably an INN 2.5 thing.
Some additional notes I forgot to mention.
This will push all of the decisions about what ports and addresses to bind
to back into innd where they belong. It will also push things like
setting socket options, creating the sockets, and so forth into innd. So
there will be some work involved in merging this, but we can take
advantage of the opportunity to clean a bunch of things up.
innbind needs an explicit list of addresses and ports to bind to (although
the address can be something like 0.0.0.0 in IPv4 if one wants to bind to
INADDR_ANY). This means that the current inndstart code which loops
through getaddrinfo and binds each socket can't be put into innbind, since
it has no way of creating sockets itself and has no idea how many will be
needed.
I'll need some help from IPv6 gurus, since I don't know how IPv6 handles
this sort of thing. In IPv4, you just bind to INADDR_ANY, and that takes
care of binding to all of your interfaces. Is there not an IPv6
equivalent? innd could walk getaddrinfo and generate a command line for
innbind, but inndstart currently allows any of those binds to fail
silently as long as at least one of them succeeds, and that's rather hard
behavior to duplicate using this architecture. Is that particular
algorithm important? Or can we do an INADDR_ANY sort of thing, or just
walk all addresses and fail if we can't bind any of them if no particular
bind address is set?
--
Russ Allbery (rra at stanford.edu) <http://www.eyrie.org/~eagle/>
Please send questions to the list rather than mailing me directly.
<http://www.eyrie.org/~eagle/faqs/questions.html> explains why.
More information about the inn-workers
mailing list