On 03/07/2018 07:39, Guy Harris wrote:
On Jul 2, 2018, at 10:34 PM, Mike Morrin <morrinmike@xxxxxxxxx> wrote:
One idea I had was to NOT give the aggregated packets real packet numbers (in the traditional sense), but give them sub-packet numbers which are displayed as x.y where x is the aggregation packet where the aggregated packet finishes and y is the aggregated sub-packet number. Note that his scheme should be extensible for sub-packets within sub-packets (x.y.z etc).
Is there any need to give them packet numbers at all? The top-level tree items can have frame numbers, but the tree items underneath that need not have one.
The project where I needed this had a logging protocol where some
low-level parameters of a real-time process were being monitored,
producing a large number of nearly identical small packets, which to
save bandwidth were aggregated and transferred every few milliseconds.
The problem I was solving was to be able to filter to find packets with
out-of-spec parameters. That can be accomplished without numbering the
aggregated packets, but if I then want to switch to an unfiltered view
and see a number of packets either side of the interesting one, I need a
handle (packet number?) to be able to find it amongst the dozens of
other aggregated packets. It is also awkward when sharing data to say
look at the 47th aggregated packet in frame 2375.
When I was working on this I could also see that the idea should be
extensible for other scenarios, such as tunneling protocols using
aggregation which might be carrying packets of other aggregated
protocols (there are examples of this in 3gpp protocols).
---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus