Wireshark mailing list archives
Re: Conversations - addresses/ports, more general endpoints, and "circuits" with their own IDs
From: Jaap Keuter <jaap.keuter () xs4all nl>
Date: Mon, 7 Jan 2019 18:16:07 +0000
On 6 Jan 2019, at 19:54, Guy Harris <guy () alum mit edu> wrote: 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?
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-request () wireshark org?subject=unsubscribe
Current thread:
- Re: Conversations - addresses/ports, more general endpoints, and "circuits" with their own IDs Luke Mewburn (Jan 05)
- <Possible follow-ups>
- Re: Conversations - addresses/ports, more general endpoints, and "circuits" with their own IDs Luke Mewburn (Jan 05)
- Re: Conversations - addresses/ports, more general endpoints, and "circuits" with their own IDs Roland Knall (Jan 06)
- Re: Conversations - addresses/ports, more general endpoints, and "circuits" with their own IDs Jaap Keuter (Jan 06)
- Re: Conversations - addresses/ports, more general endpoints, and "circuits" with their own IDs Guy Harris (Jan 06)
- Re: Conversations - addresses/ports, more general endpoints, and "circuits" with their own IDs Jaap Keuter (Jan 07)
- Re: Conversations - addresses/ports, more general endpoints, and "circuits" with their own IDs Guy Harris (Jan 07)
- Re: Conversations - addresses/ports, more general endpoints, and "circuits" with their own IDs Roland Knall (Jan 06)