Re: Help on packet correlation

[Craig Jackson <cejackson51 () gmail com>]

Thanks. That's a good start. I always forget to crawl through that
directory looking for READMEs.

My main problem is that my protocol doesn't match one of the simplifying
assumptions for the PANA code:

> The example below shows how simple this is to add to the dissector IF:
> 1. there is something like a transaction id in the header,
> 2. it is very unlikely that the transaction identifier is reused for the
>   same conversation.

The request has no identifier to ease correlation with the corresponding
response. The only correlation is their position in the conversation.

However, it looks like the example suggests the answer, without explicitly
stating it: If the VISITED flag is not set, then this is the first trip
through the dissector for this packet, and therefore the packets are being
processed in order. This would allow it to remember a pending request name
in the conversation structure, and use it when the response is handled. It
would be useful to have this documented somewhere: "If the VISITED flag is
not true, then the packets are being processed in the order they were
received."

The other interesting point is that both iscsi and rpc choose to use trees
instead of hashes to store their data. It would be interesting to have the
tradeoffs documented, especially with regards to memory overhead.

I think I have enough to proceed now.

Craig Jackson




On Mon, May 28, 2018 at 4:54 PM, Jaap Keuter <jaap.keuter () xs4all nl> wrote:

> Hi,
>
> There’s a specific README.request_response_tracking on this subject in
> the doc directory of the repository.
>
> Thanks,
> Jaap
>
>
> > On 28 May 2018, at 17:36, Craig Jackson <cejackson51 () gmail com> wrote:
> >
> > I'm working improving support for TDS. One part of the Sybase version of
> TDS involves correlation between requests and responses. A request can
> declare a cursor, and the response returns with the cursor id. As far as I
> can tell, they're only related by the request/response relationship of a
> sequence of packets.
> > It seems like this should be a common idiom. Could someone point me to
> another protocol that I can use as a model?
> > Craig Jackson
>
> ____________________________________________________________
> _______________
> Sent via:    Wireshark-dev mailing list <wireshark-dev () wireshark org>
> Archives:    https://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
>              mailto:wireshark-dev-request () wireshark org?subject=
> unsubscribe
___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev () wireshark org>
Archives:    https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request () wireshark org?subject=unsubscribe