[PATCH] Add CTDB_REQ_TUNNEL for new protocol
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
> > > > the CTDB daemon code. With this new components (e.g. cluster
> > > > 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.
More information about the samba-technical