Re: [Netconsole-devel] status?

[<li...@ho...>]

> Don't get me wrong - I'm willing to scrap all this and work with the group
> as long as the approach is reasonable.  Just relating my experiences.

Real-world experience is *good*.  I think we all have different models
of the goal we're trying to achieve, so firming that up before deciding
on a solution is a good thing.

Let me give an example protocol I thought of that's completely different
from HPA's...


The client maintains a ring buffer of output, of some convenient size, and
a 32-bit sequence number for each byte.  At any time, only a small fraction
of sequence numbers are available.

A server may query the buffer (using a well-known UDP port) whenever
it wants ("please give me X bytes starting at sequence number N").
The client returns the request, what it currently has (Y bytes starting
at sequence number M), and whatever data it has that fits into the
intersection (and the MTU).

The server can ask for 0 bytes, in which case it will just be told what
the client has without getting any.

The client never retransmits.  However, an optional but encouraged client
feature is the "persistent request".  A server sets a flag bit in its
request, indicating that it wants the client to remember the request
until all of the data that it has asked for has come in.  If the client
includes that bit in its responses, it indicates that it has remembered
the request and will be sending future unsolicited updates as long as
they fit into the window.

The window is fairly small (say, 64K limit), so the server has to refresh
its request when it's halfway gone.  If the server crashes, its request will
eventually time out on the client.

A client will hopefully have space for some small number of persistent
requests.

If the client needs to throw away the buffer, it sends a final response
with the bit *clear*.  This isn't guaranteed to arrive, but probably will.
The server always needs to do periodic pinging to make sure the clients
haven't gone away, and if the client doesn't support persistent requests
(it treats persistent requests as ordinary non-persistent requests, indicated
by not setting the persistent bit in the response), the server has to find
some suitable poll rate.

It can keep statistics on the output generation rate and adaptively poll
often enough to reduce the probability of overflow to a reasonable level.
If the client supports persistent requests, the server will only lose
data if *all* of the persistent replies get lost (so the server doesn't
notice the hole in its address space), or it fills the output table
so faster than the server's round-trip time.



This is very much output-oriented, although it can be augmented with
an input protocol - the client just maintains a sequence number and
accepts packets in sequence and throws them away otherwise.  A client
can also accept part of a packet.  In any case, it always responds with
its current sequence number.


This protocol is aiming to be as state-free as possible, to make recovery
from outages as simple as possible.  The client maintains no tomers, and
never has to throttle its output.  It sacrifices reliable transmission,
although it should perform very well over high-speed LANs.