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

[Michal 'vorner' Vaner]

Hello

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.

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

> > I guess this is clear enough (from man socket):
> 
> => ah! Why it is not TP4? Or any other stream transport protocol?

I meant it is clear that the delivery is guaranteed, not what protocol is used.

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

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.

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

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

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.

With regards

-- 
If you let 100 monkeys type, eventually one will write a Java program.
The rest code in Perl.

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-dev/attachments/20130307/08dbcae2/attachment.bin>