https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=5106
Summary: Add emem_tree_lookup32_array_le_last() or equivalent.
Product: Wireshark
Version: SVN
Platform: x86
OS/Version: Windows XP
Status: NEW
Severity: Enhancement
Priority: High
Component: Wireshark
AssignedTo: wireshark-bugs@xxxxxxxxxxxxx
ReportedBy: christopher.maynard@xxxxxxxxx
Chris Maynard <christopher.maynard@xxxxxxxxx> changed:
What |Removed |Added
----------------------------------------------------------------------------
Attachment #5040| |review_for_checkin?
Flag| |
Created an attachment (id=5040)
--> (https://bugs.wireshark.org/bugzilla/attachment.cgi?id=5040)
Patch to emem.[c|h] to add emem_tree_lookup32_array_le_last()
Build Information:
SVN 33779
--
I have a proprietary dissector that I recently added request/response tracking
capabilities to. It basically uses a 64-bit ID as the unique tracking ID,
whichi is available in both the request and response, making request/response
tracking fairly easy to do with one problem - the request is sent every second
whether the payload changes or not, and if the payload doesn't change, the ID
is exactly the same as before. This complicates the otherwise easy
request/response tracking.
So instead of getting what I expected here:
TIME INFO
(1) 1s Request #1 [Response in (2)]
(2) 1.01s Response #1 [Response to (1), Time = 0.01s]
(3) 2s Request #2 [Response in (4)]
(4) 2.01s Response #2 [Response to (3), Time = 0.01s]
(5) 3s Request #2 [Response in (6)]
(6) 3.01s Response #2 [Response to (5), Time = 0.01s]
I got this instead:
TIME INFO
(1) 1s Request #1 [Response in (2)]
(2) 1.01s Response #1 [Response to (1), Time = 0.01s]
(3) 2s Request #2 [Response in (4)]
(4) 2.01s Response #2 [Response to (5), Time = -0.99s]
(5) 3s Request #2 [Response in (6)]
(6) 3.01s Response #2 [Response to (5), Time = 0.01s]
My request/response tracking is based heavily on
doc/README.request_response_tracking and prior to the attached patch, I was
using se_tree_lookup32_array() since I couldn't use se_tree_lookup32() due to
the 64-bit ID. Everything worked fine except I noticed the occasional negative
times between request & response as in the above-described scenario. At first
I thought I could use se_tree_lookup32_array_le(), but quickly realized that
wasn't going to work. Suppose I did use it, consider what would happen if the
"Request #2" packets were absent from the capture for whatever reason. In this
case I'd get:
TIME INFO
(1) 1s Request #1 [Response in (2)]
(2) 1.01s Response #1 [Response to (1), Time = 0.01s]
(3) 2.01s Response #2 [Response to (1), Time = 1.01s]
(4) 3.01s Response #2 [Response to (1), Time = 2.01s]
... but what I should get is:
(1) 1s Request #1 [Response in (2)]
(2) 1.01s Response #1 [Response to (1), Time = 0.01s]
(3) 2.01s Response #2
(4) 3.01s Response #2
To work around this, I added a 3rd and final 32-bit key to my array, which
happens to be the frame number for the response in my case, and I also added
the new emem_tree_lookup32_array_le_last() function, whose semantics are very
similar to emem_tree_lookup32_array(), except that only the very last key is
allowed to be less than or equal. In other words, I need an exact match for
all but the last key. There's still no guarantee that a request/response will
really be exactly matched (in the unlikely case that a response takes longer
than the 1s interval to be sent), but at least I know I should never see
negative response times and I have at least eliminated those with this patch.
BTW, this "unlikely" scenario might look something like:
TIME INFO
(1) 1s Request #1 [Response in (2)]
(2) 1.01s Response #1 [Response to (1), Time = 0.01s]
(3) 2s Request #2 [Response in (6)]
(4) 3s Request #2 [Response in (6)]
(5) 3.01s Response #2 [Response to (4), Time = 0.01s]
(6) 4.01s Response #2 [Response to (4), Time = 1.01s]
Here (5) is the response to (3), not (4) but it's just been delayed so long.
Anyway, I called it emem_tree_lookup32_array_le_last() as it was very easy to
match all but the last key and only allow the last key to be less than or
equal.
--
Configure bugmail: https://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.