Socket Cache / Shared Sockets for Auth/Resolver

[Michal 'vorner' Vaner]

Hello

On Fri, Feb 15, 2013 at 10:42:59AM -0800, JINMEI Tatuya / 神明達哉 wrote:
> > 2013-02-15 13:11:32.844 ERROR [b10-auth.server_common/30868] SRVCOMM_ADDRESS_FAIL failed to listen on addresses ("Cached socket not compatible with mode SAMEAPP and name b10-auth")
> 
> > It doesn't appear that the socket cache code is documented anywhere other than the code
> > itself (which I looked at, but I'm no Python or C++ guy).  Please let me know what other
> > information, if any, would be helpful to trouble this one.
> 
> In my poor memory (it was implemented quite some time ago), auth
> requests the port so that it won't be used by any other BIND 10
> applications.  I suspect at the time of the above log b10-resolver was
> already using the port, and that's the reason for this error message.

First of, it is not documented in user documentation simply because there's no
user-visible knot for that. The cache is an internal mechanism so we can run
multiple auth servers on the same port.

However, it is quite primitive ‒ each auth simply gets its own copy of the
socket. If it was shared with the resolver the same way, there would be no way
to determine where the packets would end up (if the RD-on packet ended up in
auth or resolver), so there's a mechanism that doesn't allow sending the same
socket both to auths and resolvers.

As already mentioned, we currently don't support both on the same address/port
pair (but you still can do it by placing the auth on public interface and
resolver on 127.0.0.1 or something like that).

Though be warned that the resolver probably won't work too well, this part is
more or less proof of concept code.

With regards

-- 
The problem with graduate students, in general, is that they have
to sleep every few days.

Michal 'vorner' Vaner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <https://lists.isc.org/pipermail/bind10-users/attachments/20130218/bfd39ee3/attachment.bin>