> On 6 Jan 2019, at 19:54, Guy Harris <g...@alum.mit.edu> wrote: > > On Jan 6, 2019, at 10:30 AM, Jaap Keuter <jaap.keu...@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?
It is, just not limited to the address/port combinations most of them are right now. It incorporates the whole list of IDs that uniquely identify an endpoint in a conversation among all other endpoints in other conversations in the same capture. > > And not all conversations necessarily have specific endpoints. You mean, where the wildcards come into play? > >> 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. > Sure, so the tuple I’ve talked about would be a derived class consisting of all elements within the tuple. That makes sense. > (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.) Yes, well, “conversation” itself is not loaded in some technical context with a specific meaning (AFAIK), so allows us to make the definition for ourselves, with the flexibility it needs. Thanks, Jaap ___________________________________________________________________________ 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-requ...@wireshark.org?subject=unsubscribe