Eric S. Raymond
esr at thyrsus.com
Thu Dec 22 23:29:27 UTC 2016
Hal Murray <hmurray at megapathdsl.net>:
> I implemented the mru sort=addr
> I fixed the ^C during collection. Only a few lines.
> (Plan B was to mask the signal. There doesn't seem to be any way to do that
> from Python.)
Hm. You're right, there's no sigmask in Python 2. I never noticed that before.
Python 3 has it.
> Minor quirks:
> The frags= and limit= on the mru command are only used for the first batch.
> I'd like them to stick.
There's a computation of those for second and later span requests
that I transcribed from the C, down around line 1287 in packet.py. I'm
very reluctant to mess with it; it's at the far end of some logic that
I don't understand that seems to be trying to adapt to network conditions
or server errors or *something*.
> The recent= gets included on the request for the second batch. The server
> seems to do what we want if it gets that and also gets where-to-start info,
> but we should clean that up.
I just have. *That* part I understood.
> Major bugs:
> The low level packet processing and/or retransmission stuff is broken. I
> haven't investigated much. I've had plenty of other things to work on. The
> grab-everything case works on localhost so I can test the case I was
> interested in.
> One symptom is confusion when it gets an old (leftover from ^C) packet as a
> response when the next mru command asks for a nonce. I don't know why the
> sequence number filter doesn't catch that. We should probably flush the
> input when starting a command.
The sequence number check in the client is the sort of detail that is easy
to fluff even in a careful translation. I wouldn't be overly surprised if I'd
dropped a stitch there. Looking...
The case you describe should fail both the opcode and sequence checks,
down around line 104. If you turn on debug, do you get the sequence
> Memory usage:
> Summary: ballpark of a kilobyte per slot.
OK, that's ridiculous.
Can I have your code for reporting memory usage? I have two ideas for
reducing it. I want to make sure we're looking at the same numbers.
<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
More information about the devel