I took a peak at the tcp sequence analysis inside of packet-tcp.c...
TCP sequence analysis takes advantage of the data field for a tcp
conversation... Now without some for of extra modification, this can't
be done for tap-tcp_close because there is only ever one data field.
Unless taps/protocols can "play nice" together, taps may never be able
to use the conversation approach. Taps, in general, can have multiple
instances of the same tap, so even having one tap that uses a
conversation can potentially step on itself. Should some effort be
made to allow taps to work nicely with protocols and taps?
The idea I like best, is adding another field to conversation_key.
Maybe something such as "guint32 tap_listener_id" and force the tap
listener registration process to return an ID for each tap listener.
Possibly register_tap_listener should do this? It currently returns
1 for an error and 0 for success... Modified logic might work better:
<0 for an error and >0 (tap_listener_id) for success. If this
happened, then the standard find_conversation could use zero for
tap_listener_id, and tap listeners could have a slightly modified
find_conversation call (one that includes tap_listener_id).
