-----Original Message-----
From: wireshark-dev-bounces@xxxxxxxxxxxxx
[mailto:wireshark-dev-bounces@xxxxxxxxxxxxx] On Behalf Of Stephen Fisher
Sent: 07 October 2011 16:32
To: Developer support list for Wireshark
Subject: Re: [Wireshark-dev] Global conversation
On Fri, Oct 07, 2011 at 02:51:35PM +0200, Anders Broman wrote:
> Perhaps it could be done if we had a Global conversation to which you
> cold add a List of per protocol conversations.
We could create a new set of conversation functions, such as:
global_conversation_new()
global_find_conversation()
global_conversation_add_proto_data()
(Although using "global" makes them a bit long)
> One problem is to make it generic enough and in this particular
> scenario the subscriber number or similar would be the thing gluing
> the conversations together and that would only be Available in some
> messages. Another problem is when to create the global conversation
> e.g. what is the start.
<Using a unique piece of information, such as the phone number, would
<allow each dissector that is capable of working with that global
<Conversation to look up if it has already been created. Perhaps two
<pieces of informatino would be needed: a type of information and the
<information, e.g. PHONE_NUMBER and "+11111111111" or something more
<generic like passing a string "phone-number" and then the number
itself.
<It sounds like a good idea, but would just need a few decisions to be
<made first.
I think that it should be a bit more flexible:
* Have conversations per protocol, with 1 or more identifier keys.
* When a new identifier is observed, if it can be associated with an
existing conversation which was created with a different key, then add
the new key to the existing conversation, otherwise create a new
conversation with the new key.
* Allow conversations to be associated with conversations in other
protocols. The set of associated conversations becomes the global
conversation, but is flexible in terms of the sequence of build-up of
supporting protocols.
* A dissector can use a protocol/key pair to find a potentially
associated conversion already existing in another protocol.
* A dissector can access the set of keys for any protocol in an
associated conversation
This message contains confidential information and may be privileged. If you are not the intended recipient, please notify the sender and delete the message immediately.
ip.access Ltd, registration number 3400157, Building 2020,
Cambourne Business Park, Cambourne, Cambridge CB23 6DW, United Kingdom
