[bind10-dev] fd_share / send_fd

Danny Mayer mayer at ntp.org
Fri Apr 8 13:55:18 UTC 2011


On 4/8/2011 4:29 AM, Michal 'vorner' Vaner wrote:
> Hello
> 
> On Thu, Apr 07, 2011 at 08:44:37PM +0000, Francis Dupont wrote:
>>> Hmm, why can't there be two different versions, the same headers,
>>> but different implementations for windows and the rest, like with
>>> some #ifdef WINDOWS or something?
>>
>> => it is the idea but it needs to be less bound to PF_UNIX first.
> 
> What is bound to PF_UNIX? The fact we currently use PF_UNIX sockets for local
> communication can be changed at the only place where we connect them, the rest
> of communication should be the same. We could I hope send anything trough any
> other TCP socket.
> 
> Anyway, I don't like the idea of using IP for local communication on unix
> system, it's unusual and it will make admins nervous.
> 

Normally I would have implemented this through pipes. Domain sockets
don't port so on projects like this you need to avoid using them.

>>> Anyway, windows don't have the /proc anyway, right?
>>
>> => but it provides WSADuplicateSocket() which takes the process ID
>> at its second arguments. So it can be made pretty similar to
>> a send_fd() using /proc (same interface, etc).
> 
> Hmm, I see. But it brings complications into the unix way.
> 

Duplicating sockets is one thing but you need to look at the purpose to
see if they are suitable. You can hide lot of details by having
Windows-specific methods to wrap around the Windows part of this. I
having done this for years and did it in BIND9.

> We'll see if we can find a message bus that can transfer file descriptors for
> us. In that case this problem could just go away.
> 

The real question is why are you transferring file descriptors at all?
Or socket descriptors in this case. They are different on Windows. We
need to understand the purpose and not just say we need to do this.

Danny



More information about the bind10-dev mailing list