Want multi-core traffic generation and 10Gbps speed support in Ostinato? Please donate to help acquire hardware to develop these features
Ostinato uses a 3-part file format version - Major.Minor.Revision
NOTE: The file format version is independent of the Ostinato software version
|Major||Incremented for radical change|
|Minor||Incremented for modifications to existing protocols, fields etc.|
|Revision||Incremented for enhancements such as new protocol additions or new fields for existing protocols|
As new features are added in Ostinato, including support for newer protocols, the Revision is expected to change very frequently; the Minor version is likely to change relatively less frequently; Major is expected to change rarely, if at all.
Forward and Backward compatibility
Every Ostinato software version will support a "native" version of the file format version (typically this will be the most recent file format version as of the release of the software version).
Newer versions of Ostinato will be able to open files saved by older versions of Ostinato, only if the file format version change is in minor or revision numbers relative to the "native" file format version of the newer Ostinato
Older versions of Ostinato will be able to open files saved by newer versions of Ostinato, if the file format version change is in the revision number only - however, the enhancements in the newer version (e.g. a new protocol) will not be available.
In other words,
- Changes in major version are neither backward nor forward compatible
- Changes in minor version are backward compatible but not forward compatible
- Changes in revisions are backward compatible fully and forward compatible with limitations
File Format Specification
Ostinato files are in binary format using Google Protocol Buffers encoding.
A filename for a Ostinato file does not have a special "extension" such as .ost (although a user may use one if he desires). For identification as an Ostinato file, a fixed size magic field is used.
An Ostinato file starts with a fixed size magic field, followed by variable sized content and ends with a fixed size checksum field.
The magic field is a fixed 12 bytes in size containing -
120aa7b7 4f535449 4e41544f
The checksum field is fixed 5 bytes long; the first byte is a "tag"
0x7d while the remaining four bytes is the actual checksum. The checksum algorithm used is CRC32C
For further details on the variable sized content, look at fileformat.proto