[bind10-dev] fd_share / send_fd

[Danny Mayer]

On 4/7/2011 10:30 AM, Shane Kerr wrote:
> 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)
> 

That's correct. sockets should be treated differently than file handles
on Windows, even though they both have handles underlying the structures.

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

Windows has not historically cared about the different port numbers when
it came to privileges and rights. I haven't looked recently to see if
that has changed at all but I doubt it as it would break too many
applications.

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

Yes, Windows sockets are handles but you cannot use them in the same way
as you use file descriptors in Unix. The analogy only goes so far.

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

Well using domain sockets was a bad idea if the source is going to be
buildable on Windows. The more common code there is the less likely that
the Windows-specific part will get forgotten when making changes. So yes
it's more than just making the port easier.

Danny