[PATCH] Add CTDB_REQ_TUNNEL for new protocol

[Martin Schwenke]

On Mon, 9 Oct 2017 13:34:15 +0200, Volker Lendecke via samba-technical
<samba-technical at lists.samba.org> wrote:

> On Mon, Oct 09, 2017 at 02:29:04PM +1100, Amitay Isaacs via samba-technical wrote:
> > On Fri, Oct 6, 2017 at 7:14 PM, Volker Lendecke <Volker.Lendecke at sernet.de>  
> > > For me messaging, naming and id registration are just very tightly
> > > coupled. In Samba we have the struct server_id (a PID on steroids) as
> > > both a messaging target and existence check. I don't see the benefit
> > > having two namespaces for those tasks. But it might really be that I
> > > don't see the all requirements we have right now.
> > >
> > >  
> > There is no namespace separation. They are closely related. An endpoint is
> > uniquely identified in cluster using server_id (or subset of it), srvid
> > alone is
> > not sufficient. Even though smbd only uses srvid for registration, ctdb
> > converts that internally to information similar to struct server_id by
> > querying pid using the socket.  SRVID alone is just for messaging.
> > 
> > The only reason for introducing tunnels is to overcome the limitation
> > in the srvid based registration.  If we resurrect server_id based
> > registration with improvements, and both smbd & service daemons
> > are using the same registration mechanism, then we stick to using
> > srvid based messaging and sub-protocol definition.  
> 
> This started out as my questions why the tunnel overlay is really
> needed. I am of course not blocking it, I just wanted to understand
> it. That failed, but I'm happy to not understand everything, so just
> put it in :-)

Reviewed-by: Martin Schwenke <martin at meltin.net>

We'll wrap this in the client code and then we can always reimplement
the transport handling in the client code.  That will avoid churn in
the new daemons.

Pushed...


peace & happiness,
martin