[PATCH] Add CTDB_REQ_TUNNEL for new protocol

Amitay Isaacs amitay at gmail.com
Thu Oct 5 14:01:31 UTC 2017


On Thu, Oct 5, 2017 at 9:51 PM, Volker Lendecke via samba-technical <
samba-technical at lists.samba.org> wrote:

> On Thu, Oct 05, 2017 at 09:47:38PM +1100, Martin Schwenke wrote:
> > Hi Volker,
> >
> > In case Amitay is completely gone for the evening... he will probably
> > explain more eloquently...  :-)
> >
> > On Thu, 5 Oct 2017 12:17:40 +0200, Volker Lendecke via samba-technical
> > <samba-technical at lists.samba.org> wrote:
> >
> > > On Thu, Oct 05, 2017 at 03:59:17PM +1100, Amitay Isaacs via
> samba-technical wrote:
> > > > This is the last set of preparatory patches required for the
> refactoring
> > > > the CTDB daemon code.  With this new components (e.g. cluster
> manager,
> > > > database daemon) can design new protocol and use current CTDB daemon
> as a
> > > > cluster-wide transport.  This allows us to incrementally carve code
> out of
> > > > CTDB daemon.
> > >
> > > This looks really interesting. Question -- what *is* a tunnel?
> >
> > Tunnelling provides a new low-level packet type.  A tunnel is then a
> > bunch of ctdbd processes registering an common tunnel identifier that
> > allows Unix-domain-socket-connected daemons on different nodes to
> > communicate with each other. This means the new daemons can have
> > new, independent protocols and use ctdbd as a transport by wrapping
> > their packets in tunnel packets.
> >
> > Later, if we want to, we can re-wire the communication between these
> > daemons using some other transport (e.g. proxy).  However, for now we
> > just use ctdbd as the transport because it exists and this
> > implementation is cheap.  :-)
>
> Our messages are sequenced and reliable. Why not use those?
>
>
Are you talking about source3/lib/messages_ctdb.[ch]?

As you might have guessed, the tunnel implementation is pretty similar
to srvid mesages.  One of the main differences is you can register
an endpoint with unique id only once on a node.  It's essential that
there is only one "service" daemon (e.g. database daemon) running
on a node.  Also, you cannot tunnel a packet between two different
tunnel ids.  I feel this will ensure that the design of a "service" will
remain coherent and there will be cleaner interfaces between services.
That's why I decided to avoid srvid based messaging to forgo the
temptation of violating inter-service interfaces.

Amitay.


More information about the samba-technical mailing list