[PATCH] prepare streams based messaging

[Amitay Isaacs]

Hi Volker,

On Tue, Jun 21, 2016 at 5:47 AM, Volker Lendecke <vl at samba.org> wrote:

> Hi, Amitay!
>
> On Mon, Jun 20, 2016 at 03:29:20PM +1000, Amitay Isaacs wrote:
> > The fcntl lock on lockfile is lost when you become daemon (rather when
> the
> > parent goes away).  I can start another instance of tfdd and it will
> > happily overwrite the previous lockfile and the socket.
>
> Thanks for pointing this out! Attached find the next round that should
> fix both issues :-)
>
> > It's rather tricky to test the existence of tfdd by trying to connect to
> it
> > since tfdd writes to the socket immediately.  We either need to ignore
> > signal SIGPIPE on the initial write or may be just rely on existence of
> > process?
>
> We need to make tfdd as robust as possible, so this was a very obvious
> bug, thanks for finding it!
>
> > Doing a connect test is much better since it also tests the
> > responsiveness of tfdd.  But there is no recovery mechanism in tfdd in
> case
> > it is stuck.  Considering that tfdd is "simple" process (i.e. it's
>
> What would be the way out if tfdd is really stuck? The lockfile is held,
> the socket is bound, what shall we do? I think this is about as bad as
> the file system being stuck, at least from my point of view.
>

> My plan is also to exit all processes connected to tfdd when it dies,
> at least initially. Making that recover-save would be non-trivial,
> we'd have to implement something like a "grace" mode to allow everyone
> to register its unique id given in the last incarnation. Or we need to
> store the unique ids persistenly on disk. I'm not sure I like either of
> both, at least until people force us to make it tfdd-crash safe.
>

Since one of the motivation of tfdd is to avoid file system access, I agree
that storing unique ids in a database is not helpful. Unless we clearly
define the recovery process, let's not worry about it.  Just focus on
making tfdd as robust as possible.


>
> New patch attached :-)
>

Now the code looks much better, I have not managed to crash it as yet. :-)

I have attached few minor fixes to the code. Removing unused code and one
case of handling error condition.

There are two issues that need some thought.

1. One bottleneck I see in the code is the linked list of clients to find
matching tfdid.  We might need to add an index (rb-tree or hash table) for
tfdid to client mapping.

2. Currently tfdd allows registration of multiple tfdids.  Even though tfdd
sends fd to the first client with matching tfdid, it does not verify if a
particular tfdid is registered more than once.  Any checking of tfdids is
going to complicate the protocol.  So the question is do we complicate the
protocol or rely on everyone collaborating to ensure we never have same
tfdid registered more than once.

Amitay.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: tfd.fixes
Type: application/octet-stream
Size: 2968 bytes
Desc: not available
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20160622/7a482eba/tfd.obj>