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

[David Aggeler <david_aggeler () hispeed ch>]

> > So does that mean that DICOM multiplexes multiple sessions over TCP?

Yes. FYI, its called presentation context ID.

> >  At some point, the conversation mechanism should probably be generalized, so that arbitrary protocols
> >  can define conversations, with TCP/UDP address-and-port-based conversations are just a particular
> >  subclass of the general class of conversations.

DICOM endpoints also need to manage this de-multiplxing, so I don't think it is that wrong to do this in the dissector.
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.

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

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. Then, other protocols, also relying on the same TCP mechanism, wound not 
need their own hash tables, to manage something, that is one layer below.


___________________________________________________________________________
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