Wireshark · Wireshark-dev: Re: [Wireshark-dev] fragment_add_..(), pinfo->src/dst, IP vs. TCP Session

[Guy Harris <guy@xxxxxxxxxxxx>]

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.)