[rrd-developers] [PATCH] rrdcached "SLURP" for extreme update rates

[kevin brintnall]

Tobi,

I thought about it a little..  We can restrict it to the daemon user (who
arguably could do just as much damage to the files anyway).. but the file
system case introduces some strange race conditions.

> There are a couple difficulties there..  You may not know how many lines
> you'll be submitting until you're done (unless you buffer them all in
> memory first to count them).  To get around that, we would need some sort
> of special command to terminate output, and a finite state machine to
> track which state we're in.

I think this is the way to go...  We will have to convert the daemon to
stdio, but that's something I want to do anyway.  We will have to be
careful to fflush() in the right places to avoid deadlock.

As long as one side of the protocol always knows when to block, we should
be OK.  In other words, it will still be synchronous, but potentially with
much larger exchanges.

    ->	MULTIUPDATE
    <- 	0 Go ahead.  Terminate with '.' on its own line (is this necesary?)
    ->	x.rrd 1:2
    -> 	y.rrd 2:3
    -> 	.
    <-	2 results
    <- 	x.rrd ??
    <-	y.rrd ??

A few questions:

 ? Should we do without the initial "0 Go ahead"?

 ? how do we match up updates/responses?
   - if using a separate key, how do we separate from the filename?
   - what if the user doesn't care about response? (empty key?)

Let me know what you think...  I'll get started on converting to stdio.

-- 
 kevin brintnall =~ /kbrint at rufus.net/