> 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

Reply via email to