Replay progress report
Eric S. Raymond
esr at thyrsus.com
Wed Jan 6 15:56:32 UTC 2016
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
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
> 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
<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
More information about the devel