On Jul 11, 2010, at 1:45 PM, David Aggeler wrote:
> DICOM endpoints also need to manage this de-multiplxing, so I don't think it is that wrong to do this in the dissector.
I wasn't saying it wouldn't be done in the dissector.
I was saying that there would be a base class of conversations, which would *NOT* have addresses, port numbers, or anything else to identify them - what they'd have would probably be just
a unique ID generated by the conversation code;
private data attached to it by dissectors;
and the current types of dissectors would be subclasses of those, adding additional data and functions to look up conversations based on a key and add new conversations.
This idea is at least in part inspired by Network Monitor's general notion of conversations:
http://blogs.technet.com/b/netmon/archive/2006/11/15/conversations-in-network-monitor-3-0-cable-talk.aspx
If we implement that, we could provide similar UI features.
> The different presentation context IDs are already stored in the DICOM conversation data structures. I would currently not quite see how I would 'subclass' the conversations.
Your conversations would probably have, as the key, the conversation ID for the TCP connection and the presentation context ID.
>>> session aware protocols ...
>
> I probably should have called id transport layer. E.g. for the DICOM Query/Retrieve Mode, it has a command channel open and a data transfer channel. This separation is provided by TCP sessions.
Meaning TCP connections, i.e. the command channel and data transfer channel are on separate TCP connections?
> DICOM does not have any sequence number in its protocol data (or data re-transmit capabilities) so it is using TCP to provide all of this. It's expecting the lower layer to deliver the packets in order and consistent. So that's what I kind of 'expect' from the reassembly module.
That's what the fragment_add_seq routines are for - protocols that require reassembly, and that run atop a protocol that provides reliable, sequenced delivery. (The TCP dissector should probably be changed to use the reassembly mechanism to deal with out-of-order arrival of segments; it doesn't currently do so.)
