Comment # 20
on bug 8287
from Evan Huus
(In reply to comment #19)
> 4. Is an array even the right data structure to use here? Based on the
> search patterns I'm seeing in the code, I suspect a hash table or binary
> tree would be possible, and algorithmically faster. (Ironically, binary
> tree's are something wmem doesn't do yet, so you'd be back to emem if you
> wanted to make use of those).
Upon further reflection, I think the optimal choice would be a doubly-linked
list embedded in the struct I suggested above, with a tail pointer in the
conversation data and a pointer to each actual node in the packets' proto_data.
I believe that should permit all required operations in fast constant time.
> 5. I believe the matching will fail if you see packets not in a strict
> req-res order, for example REQ1, REQ2, RES1, RES2. This is a perfectly valid
> order, and quite common in reality since browsers frequently make several
> requests near-simultaneously. Am I missing somewhere where you handle that?
I'm not sure what I was thinking here - clearly multiple interleaved
request/response pairs will have to be in different TCP conversations so your
patch won't see them as interleaved at all. There may still be an issue with
TCP retransmissions (or missing packets) but at least in that case the stream
is actually abnormal, so getting confused is not unexpected (obviously figuring
it out and displaying an expert info would be ideal, but I'm not sure how much
work that would be).
You are receiving this mail because:
- You are watching all bug changes.