connection $history - 'g' for gap

Development
1

I'm finding it would be handy to be able to glance at a connection log line
and know that the analysis for the connection experienced a content gap.
For example, this can immediately explain why DPD failed to identify a
known server.

Proposal: add 'g'/'G' connection history values, scaled in the same
exponential way as for 'c', 't' and 'w'.

Any thoughts/objections before I go ahead and implement this?

    Vern

2

It might be valuable to have some (optional) way of accessing the byte counts consisting the content gap(s). If the content gap is somewhere in a long tail, but DPD still fails, then the explanation could be something other than a content gap.

On the other hand, maybe you’re just thinking about content gaps at the head of a connection before it has been fully analyzed.

3

I think it would be useful. I can't believe we hadn't already thought of adding that!

  .Seth

4

It’s one of these brilliant ideas that I cannot believe we haven’t got yet :wink:

Let’s implement it.

5

This is the missed_bytes field:

missed_bytes: count &log &default = 0 &optional
Indicates the number of bytes missed in content gaps, which is representative of packet loss. A value other than zero will normally cause protocol analysis to fail but some analysis may have been completed prior to the packet loss.

6

Thanks. I was thinking of something a bit different - the total amount of the content gap is useful, but in some cases it might be useful to know where the content gaps occurred, whether in the head of the connection, which likely is impactful for protocol analysis, or in a long tail, where it probably doesn’t affect analysis.

Perhaps some tunable setting indicating that “I only care about content gaps in the first 10K (or whatever) of the connection” could address that…

7

I like the idea of logging gap ranges for a connection. Could a vector be used to store gap start and gap stop offsets?

-AK

8

I don’t think we’d add that to the default log, but you should be able to write a script that does something like that.

.Seth

9

That could get very messy in the real world. How about start of first gap, length of first gap, total number of gaps?

(www.blackberry.com)

10

That could get very messy in the real world. How about start of first gap,=
length of first gap, total number of gaps?

I think if the goal is to know whether DPD failed due to content gaps,
much better than trying to infer that from a set of gap information would
be for dpd.log to include "no DPD decision because ran into a content gap"
or such.

    Vern

11

Agreed, but I think there is broader use for knowing, from the conn.log, that there were gaps. I think the 'g' character would address that.

I've always loved the history field and have found numerous uses for it over the years.

Kevin