Re: Conversations - addresses/ports, more general endpoints, and "circuits" with their own IDs

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

On Jan 6, 2019, at 10:30 AM, Jaap Keuter <jaap.keuter () xs4all nl> wrote:

> Rather than simplistic endpoint ID’s I think we need an ID tuple per endpoint,

How is a tuple not itself an ID?

And not all conversations necessarily have specific endpoints.

> which may be combined with one (or more) other tuples representing single (and multipoint) connections.
> Examples are an aggregating tap/monitor port which monitors various VLANs, or an MPLS link. Or even closer to home, a 
> multi port capture in a pcapng file, lets say of two ports of a switch or router. The conversations therein would 
> need to be identified from the capture interface on up.

The intent here is to have a general concept of a "conversation", with no specification, at that layer, as to how a 
"conversation" is identified - think of it as an abstract base class - with subclasses that use different ways of 
identifying whether a packet belongs to a given conversation or not.  Multiple subclasses can share code for 
identifying that; TCP and UDP might share the "IP address and port" identification code.

(I"m not sure I like the name "conversation", but I'm not sure I like "flow" as that strikes me as half of a 
conversation going in only one direction, and I'm not sure what other name would be good for that broad a concept.)
___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev () wireshark org>
Archives:    https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request () wireshark org?subject=unsubscribe