 |
SPP - Synthetic Packet Pairs
Architecture
This section contains a few notes about some of the software's internals.
Program Modules
The program is constructed of two main types of modules. The first type is the SPP processor itself, and the second is the data collector. The job of the data collector is to construct a list of <pkt_id,timestamp> tuples (refered to as 'instances' internally) from either a file, live interface, or remote interface which can then be used by the SPP processor. Generally, SPP will operate with three threads. One to carry out the SPP algorithm, and two data collector threads which which read data from measurement points. When in a master and slave configuration, the master will use three threads as usual, however the slave will only have two since it only requires one data collector.
SPP Sample Frames
When using remote interface monitoring, SPP Sample Frames are sent to the master from a slave. They include the data necessary to construct the <pkt_id, timestamp> tuples as well as direction for every packet of target traffic observed.
The frames begin with a pseudo RTP header. (The intention is to move to correct RTP implementation in future versions).
The SSF header contains a few pieces of vital information. The RTP field in which this information is stored is shown in brackets.
- SSF format code [pt]
- Seconds component of timestamp - 4 bytes [ts]
- Microseconds component of timestamp - 4 bytes [ssrc]
After the header comes many entries of observed packets.
The default 'instance' format is as follows:
- 32 bit ID
- 1 bit Direction
- 15 bit Timestamp diff
In practice, length of the timestamp diff can be set to 1 to 4 bytes (including the direction bit).
Timestamps are calculated by adding the diff from the current instance to the timestamp of the previous instance. For the first instance in the SSF frame, the diff is added to the timestamp contained in the header.
|
