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 <[email protected]> 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 <[email protected]> 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 <[email protected]> > Archives: https://www.wireshark.org/lists/wireshark-dev > Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev > mailto:[email protected]?subject= > unsubscribe
___________________________________________________________________________ Sent via: Wireshark-dev mailing list <[email protected]> Archives: https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:[email protected]?subject=unsubscribe
