[Guy Harris <gharris@xxxxxxxxxxxx>]

On Wed, Jan 03, 2001 at 07:31:16PM +1000, Richard Sharpe wrote:
> Yes, this is a problem ... and always will be so ... Your dissector needs
> to be robust enough to work in the face of missing or duplicate
> frames/packets/segments.

...given that

	1) the frames really may be missing, as in "a machine failed to
	   transmit them" (either the originating machine or an
	   intermediate router);

	2) the machine running the packet capture program may have
	   dropped the frame because, for example, there was too much
	   traffic for it to handle;

	3) the capture may have started after the first frame was
	   transmitted.

> There are no procedure/functions for dealing with this as yet, and while
> there has been much discussion, I am firmly of the view that there is no
> good solution to the problem, because there will always be cases where data
> is missing, out of order, duplicated, etc.

At least for TCP, out-of-order and duplicate data could probably be
handled by the TCP dissector, at least for Ethereal when it's read a
capture.  (The same probably applies to other connection-oriented
transport protocols.)

Missing data, however, obviously can't be handled by the TCP dissector
unless it's capable of reaching back in time and finding out what was on
the wire when the capture program wasn't watching, or what some machine
was supposed to transmit but couldn't....

Furthermore, if you're doing a "Update list of packets in real time"
capture, or a Tethereal capture that's printing packets as they arrive,
either the display update/printing will have to be delayed until
the packets preceding out-of-order data arrives, or the dissection will
have to deal with the data as it appears in the capture.