I often need to analyze FIX messages and doing this I could really need a way to be able to create a "calculated field".
e.g. - I have a trace containing FIX stream - I have the OS timestamp when we received the message - I have the FIX time stamp inside the message in SendingTime (Tag52)
To be able to analyze this closer it would be VERY beneficial if it was possible to create a "Calculated Column" and report on that.
It should be able to specify which field use - e.g. New Column name FIXDelay = Tag52-OSTime. This would give a quick picture of the delays caused in the FIX stream. Of cause a way to create a graph for this would also be GREAT!
The above is just and example, but to be able to create a Custom Column that will show results based on a formula using fields from the protocols would just be great.
Doing this as custom-calculated fields makes more sense, as arbitrary fields can be applied as columns already, and we would also presumably get filtering etc. for free.
There will have to be a fair amount of thought put in to handle all the various types and cases etc. properly.
What if there is just one foo and multiple bar but always at least one and then be able to choose which instance of bar to use Foo – bar[1]
At least in display filter language [] is slicing operator, and bar[1] means first byte of bar.
We could use bar{1}, but what if bar{1} not exists?
Problem is that you don't know about it at compile time.
In such cases should we display warning runtime?
Instead we could add new functions like: sum(), avg(), max(), min() which returns single value [or 0 (NULL)? when there's no item], or
maybe we should not implement it as custom columns, just add new 'report generator dialog' which allows SQL-like queries on pcap file?
Hi,
The example bar[1] was just an example – in some scripting language this meeans first element in the array. We can later go into the semantics around this.
Never mind, the most important thing is that you understand what I meant and the functionality I'm referring to – which I’m sure you got ;-)
Adding new report capabilities with SQL like queries could also be a possibility – this would make it possible to make a graph showing the interesting points which could be used to narrow it down to the exact frame of interest. Also the graphing capabilities would make it easy to use for reporting and explaining to others.
-Ib
The example bar[1] was just an example – in some scripting language this meeans first element in the array. We can later go into the semantics around this.
Yes, to implement this I need exactly know how it should work :P
I stated some basic problems which I don't know how to handle.
We can go later into details, but I'm not so sure if I'll have time later.
For me any semantic will work, please just state it here to allow other users to comment.
The example bar[1] was just an example – in some scripting language this meeans first element in the array. We can later go into the semantics around this.
Yes, to implement this I need exactly know how it should work :P
I stated some basic problems which I don't know how to handle.
We can go later into details, but I'm not so sure if I'll have time later.
For me any semantic will work, please just state it here to allow other users to comment.
Is it possible to just implement the ability to create a custom column for a specific offset? Please see my example outlined in bug #10154 (closed), which was closed because it is thought to be a duplicate of this bug.
Is it possible to just implement the ability to create a custom column for a specific offset? Please see my example outlined in bug #10154 (closed), which was closed because it is thought to be a duplicate of this bug.
Somebody might think it's a duplicate, but I don't. I reopened it (and asked some questions, which should be answered in that bug, not here).