>
>This wouldn't be trivial to implement, though the measurement could be
>done fairly simply:
>
>One could, of course, rely on very synchronized clocks between packet
>capture devices and very accurate timestamp recording and simply
>measure deltas between packet arrival times between captures.
Using NTP to sync the capturing stations to a common time source should
provide a consistent time for recording timestamps at each point. Of
course there could be some minor clock drift, but it should be accurate
enough that the drift is not going to have a significant impact on the
results.
>Perhaps a bit more accurate under non-ideal conditions (where
>synchronization of host clocks on the recording devices cannot be
>guaranteed), one could keep a (perhaps smoothed) log of deltas between
>host clocks by observing arrival times of packets passing in two
>directions - (d1-d2/2 = average latency, where d1 is the time between
>observing of a packet flowing one direction and a later packet flowing
>the other direction (possibly a reply to the first packet) in one
>capture, and d2 is the time difference between observing the same two
>packets in the other capture)).
>
>However, it'd be difficult to do, especially for all types of traffic.
>For one thing, a mechanism for "fingerprinting" traffic has to be
>devised - how does the software know that a packet in one capture is
>the exact same as one in another capture? With protocols like TCP
>there's enough information to build a reasonably reliable
>"fingerprint", but not necessarily possible with other protocols.
>Ethereal really doesn't have the infrastructure at this point to
>process this, either...
One should be able to perform a hash on each packet to compare the two
trace files or at a worst case perform a bit comparison of each packet.
(If that were the only way I would want some massive CPU to throw at it.)
You would also have to account for the possibility that packets wouldn't
necessarily arrive in the same order at each capture point so you would
possibly have to search through the entire second capture file to locate
the same packet.
This might start just with focusing on the TCP protocol initially and
expand it into other protocols after further studying of each protocol to
determine the best way to fingerprint each packet.
>However, it could be done and would be a very interesting project for
>someone, I'm sure. Now we just need a volunteer =)
>
>Ian
Hmm, looks like we have found our volunteer. Now he just needs to dust off
his C programming books and start reading some source code. =)
Steve