Hello all, I am capturing interactive rendered streaming application over HTML5, and each video packet from the sender is 12 to 13KBytes, which is segmented by TCP to 8 or 9 TCP segments. At the receiver the video packets are also segmented by the receiving host. I am identifying the video packets by the PTS of Matroska container format, which is written only to the first TCP segment of a video frame. In case of re-transmissions, the missing video data segment is sent after the next video frame is arrived. Does wireshark have some mechanism to identify that the data belongs to the previous video packet? Does the application layer or the video decoder re-arrange the piece of data and wait until the right data segment is arrived to play the video stream? Thanks in advance! Tilak asked 03 May '16, 05:47  Varisetty |
One Answer:
"Segmented" in what sense? The code that's reading from the connection on the receiving host might see all the TCP segments as the results of separate reads, or might see all the data in one read, or might see some other consolidating of segments into reads. Is that what you're referring to? Wireshark, by the way, will not see that - it doesn't see what happens in the receiver's TCP stack. (Well, if Wireshark is running on the receiving host, and the receiver's network adapter is doing desegmentation, and the receiver's network stack is supplying the desegmented packets to the part of the stack that does packet capture, Wireshark will see the desegmented packets.)
If the video packets are being reassembled by Wireshark, yes - the dissector for the video packets is, somehow, identifying packet boundaries and telling the TCP dissector when it needs more data, and the TCP dissector is reassembling the data as necessary. How it identifies packet boundaries depends on the protocol - TCP does not provide any mechanism to identify higher-level packet boundaries, so it needs the help of dissectors that run atop it, for example, from each packet beginning with a length field.
No - the rearrangement of the data is done by the receiving host's TCP implementation, and it supplies reassembled, in-order data to whatever code is reading that data. answered 03 May '16, 18:16  Guy Harris ♦♦ |
thanks Harris for the explanation. My question was about the segmentation and not particularly about the read call from the socket, but it is a good point to highlight.
So, you mean the application layer protocol has some dissectors that identify the packet boundaries, and communicate to TCP that the packet boundaries have not arrived yet?
Thanks! Tilak
Yes, the dissector for a protocol running atop TCP identifies packet boundaries and:
This is somewhat similar to what an implementation of a protocol running atop TCP has to do in the receiving code, although it's somewhat simpler due to it being able to "pull" data from TCP by doing a read, rather than, as is the case with dissectors, having TCP "push" data to the subdissector, so if a protocol implementation needs only N bytes of data, it can, at least in most operating systems, read just N bytes and leave the remainder of the bytes for it to read later.