[bind10-dev] Resend: Re: proposed system design and inter-process protocol for shared memory

[Francis Dupont]

> On Thu, Mar 07, 2013 at 10:25:30AM +0000, Francis Dupont wrote:
> > > As a matter of fact, I still believe that is TCP.
> >
> > => no, PF_UNIX doesn't use any network protocol: it just moves buffers.
> 
> It may or may not. I don't really care what happens inside
> kernel. What I meant the whole time is it acts _like_ TCP from
> outside.

=> it is still not correct: what you can say is both implements
the same transport service abstraction.

> > >   socket(AF_UNIX, SOCK_STREAM, 0)
> >
> > => should be PF_UNIX in place of AF_UNIX even protocol families and
> > address families have always the same value.
> 
> Really? I just took this from man socket! It does say AF_, not PF_.

=> use a real OS, i.e., BSD and not Linux, where the man socket is
correct and says the domain parameter is a protocol family.

> > BTW please remember PF_UNIX SOCK_STREAM provides really a stream
> > so doesn't preserve packet boundaries! If for instance you use one
> > to send two control messages in two send()s, a recv()s at the
> > other end can return the first message or both. I had already
> > a trouble with this (solved by moving to SOCK_DGRAM which was
> > I needed in fact) and of course debugging had enough impact
> > to never show this phenomenon (:-)...
> 
> Don't worry, we use it that way. We have a 4-byte length prefix with each
> message and then that many bytes are the message. And we do retry the read
> if it reads less that as many bytes.

=> reread my message: the issue is not less but more, so not about
retry but about possible tail recursion of the decoding routine.

> With SOCK_DGRAM, we do not have the guarantee of delivery nor order,
> so they are not suitable. Also, the messages might not fit, because
> SOCK_DGRAM might provide only messages up to some size.

=> datagram transport is another abstraction. The interesting property
in the case I was about is the atomicity.

> What we could have used was SOCK_SEQPACKET, but the support in some
> libraries might be problematic (like in C++ asio).

=> it was not suitable in my case, mainly because it was not
available everywhere at those days.

> > A final note: PF_UNIX is UNIX, not POSIX. So it is NOT portable.
> > TCP to 127.0.0.1 or ::1 provides the same abstraction and is
> > portable (at the exception of the Windows 8 modern UI where it
> > is a privileged operation but this environment will *never*
> > support a "desktop" application like BIND 10).
> 
> And it also creates problems when running multiple instances from multiple
> directories and may be slower and we would need authentication on it.

=> what is the "it" here? TCP has nothing to do with directories,
is slower than PF_UNIX SOCK_STREAM and offers less access control.

> I guess we will support msgq over IP eventually, both for windows and for
> clusters, but I don't think we need to consider that right now.

=> I am concerned with any design choice which is incompatible with WIN32.

Regards

Francis Dupont <fdupont at isc.org>