https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=4714
--- Comment #4 from Sake <sake@xxxxxxxxxx> 2010-05-24 01:13:59 PDT ---
(In reply to comment #3)
> (In reply to comment #1)
> > The number assigned to the TCP stream has a file(-set) scope and is based on
> > the conversations identified in the file. Conversations are a generic mechanism
> > to track exchanges between two identifiable endpoints. This happens on many
> > protocol layers. Therefore no significance can be drawn from the value other
> > then a correlation between equal numbered frames.
> > In this case the DNS exchange also constitutes a conversation.
>
> Also, disabling the http dissector does not have an effect on the tcp.stream
> numbers as disabling the dns dissector does. My fundamental comment is that
> application layer decoding or dissecting (or lack thereof) should not impact
> this tcp.stream field. tcp.stream should be consistent no matter what
> application dissectors are active.
I was the developer that introduced tcp.stream. The goal was to be able to
distinguish between tcp session, even though they might have the same ips/ports
tuple (reused ports). I thought about keeping track of TCP streams separately,
but that would mean adding another global variable to keep track and adding a
stream number to every TCP sessions conversation data. I made the decision not
to increase the memory footprint of Wireshark.
I still believe that was the right choice, as the stream index is not something
inherent to the traffic (try saving a part of the capture file to a new file
and the indexes change, even when they would just count tcp sessions).
I do understand that it can be less useful when communicating about tracefiles,
but I think it's no problem to say "Look at the tcp session starting in frame
X" instead of "look at tcp stream X".
--
Configure bugmail: https://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.