[bind10-dev] fd_share / send_fd

[Shane Kerr]

Francis,

On Thu, 2011-04-07 at 10:24 +0000, Francis Dupont wrote:
> Some questions about fd_share / send_fd:
>  - it seems there are two versions of them today: src/lib/xfr and
>   src/lib/util/io. It seems it is a simple code reorg, i.e.,
>   the code moved from xfr to util/io (BTW this is a good idea)

Probably this should sit in our new BIND 10 utility library.

>  - what kind of descriptors are moved? on some systems file
>   descriptors and "socket" file descriptors are different
>   (cf. Windows file and socket handles, note both can be
>    sent to another process and they are more different than
>    one could believe, e.g., close functions are different too!)
>   (it seems sockets, cf xfr code)

Right now we only move sockets. We have 2 use cases:

     1. TCP connections arrive at the authoritative or recursive
        resolver and need to get transferred to the XFR out process.
     2. In future we'll have our privileged socket creator which will
        create all sockets on ports < 1024 and need to transfer those
        bound sockets to other processes.

>  - there are other ways to send a file descriptor, for instance
>   one can open /proc/<other_process_id>/fd/<file_descriptor_number>
>   on Linux or in general any OS with /proc file system.
>   I'd like to get a fd_share / send_fd clone using this /proc way
>   (IMHO it is far closer than PF_UNIX to what Windows support,
>    and this can remove some dependencies too).

Hm... by default FreeBSD doesn't mount the procfs, and it doesn't look
like it ever supported the "fd" directory.

With Windows I was assuming we'd use something like DuplicateHandle:

http://msdn.microsoft.com/en-us/library/ms724251%28VS.85%29.aspx

In theory we should be able pass sockets around with this function,
since according to the documentation sockets are also normal Windows
handles:

http://msdn.microsoft.com/en-us/library/ms740522%28v=VS.85%29.aspx

Note that I haven't tried this stuff.

Is there a potential benefit to poking around in /proc other than making
a Windows port easier?

--
Shane