Re: fragment_add_..(), pinfo->src/dst, IP vs. TCP Session

[Guy Harris <guy () alum mit edu>]

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.)
___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev () wireshark org>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request () wireshark org?subject=unsubscribe