Replay progress report

[Eric S. Raymond]

Hal Murray <hmurray at megapathdsl.net>:
> 
> esr at thyrsus.com said:
> > This scheme depends on the assumption that, before the main loop, intercept
> > functions will be called in the exact same order during replay that they
> > were during capture.  There's no separate replay interpreter that is
> > dispatching events itself, so there is no way to handle a getaddrinfo event.
> 
> Ahh.  I think you need a dispatching layer.  DNS is just the tip of the 
> iceberg.

You may be right, but this is complexity I am strenuously trying to
avoid while I get the basic function up.

> You also need to handle timeouts from the select and anything else the normal 
> main loop does.  That includes signal handling.  I think most of the signal 
> handlers just set a flag then the main loop notices the flag and does the 
> work.
> 
> Currently, the only interesting signal tells ntpd to exit.

Right, that doesn't require a full dispatch layer.

> There are signal handlers to incr/decr the debug level.  I think those get "processed" at interrupt level.  That will be hard to intercept.  Do we want to replay debugging stuff?

Maybe eventually, but that is way fancier than I want to try to get yet.

> I think there is an I/O signal handler.  The idea was to grab arriving packets "now" to get a better time stamp in case the CPU is tied up doing crypto, and queue them up for the main loop to process.  That isn't necessary if the kernel time-stamps arriving packets.  I haven't looked for this code.

That's in the part replay nrcessarily bypasses.

> Refclocks will add another place to dispatch.
> 
> You will also need to intercept PPS.

I belive this is what is most likely to force me to a full dispatch layer
eventually.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>