> Anders Broman skrev 2011-10-07 18:10:
> > Mike Morrin skrev 2011-10-07 17:48:
> >>
> >> 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
> How about something like
>
> * proto_conv_new(proto ,key(s))
> Check if global/top/main conversation exist by matching the key with
> other protocols using that key.
> ( string key looking in a (hash)table of strings finding list of proto_conv ?)
> if not create it and create the proto_conv.
> Return proto_conv and possible top_conv
>
> * proto_conv_add_key(proto, key(s));
> if a new key has turned up in the conversation look if there are matching
> proto_convs with a
> different top_conv if true join them.
>
> I'm sure there are many pitfall here and with phone call as an example what
> if two consecutive calls are made how to differentiate between them.
Not sure that this as big a problem as it first seems: at some layer at least the protocol itself has this ambiguity, so it can provide an "end of conversation" explicitly - in fact I have previously thought this would be a good thing to add to the current conversations to distinguish re-use of identifiers in a new conversation.
> Another mater is performance and memory consumption.
One awkward relationship to consider is that conversations in different protocols at different layers have different multiplicity relationships with the conversations above and below them, e.g. a MAC layer conversation may have multiple RLC conversations carried over it (or specifically in 3G, an RRC connection can be associated with multiple RABs), and in some cases a high level "call" may be carried over several different bearers (e.g. in 3G SRBs and RABs associated with voice call). It would be really useful to be able to filter on this relationship at any level, so a filter on a conversation at a layer which includes a multiplexor may get multiple higher layer conversations included, and filtering on any one of these higher conversations excludes the other higher layer conversations, but still includes the lower layer multiplex conversation which carries it.
Perhaps you could consider "conversations" to be any such general relationship between endpoints, no matter how dynamic, e.g. in 3G TCP/IP/Ethernet terms, an Ethernet "conversation" can carry multiple IP conversations (and other protocol conversations), each of which can carry the TCP conversations, each of which may carry signalling for (typically more dynamic) higher layer conversations.
Or has this abstracted too far? If the above could be made to work in a general way, the current bloat of the packet info structure might be reduced, as it tends to get custom data to handle some of the specific relationships.
Neil
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