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
