-
Notifications
You must be signed in to change notification settings - Fork 32
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Boundary padding for records and PDUs #53
Comments
RecordSpecificationElement from RecordSpecification (from 6.2.73) in particular is tricky because the recordLength is variable and depends on the recordID. recordID is a 32-bit enumeration with lots of potential record types, and DIS7 does not mention any restriction of those record types to a specific subset! 😱 I have managed to narrow down the classes that use RecordSpecification to the following three classes:
Record-R and Set Record-R PDUs do not mention any restriction of recordIDs, though from the purpose of the PDU it may be gathered that this is meant for setting simulation parameters (I am guessing enum values 45000-52530 in [UID 66]). Transfer Ownership limits the possible records to the following:
|
Hopping back into this again. I looked at the record classes requiring padding again, and at the PDUs that use them. It looks like Transmitter PDU is one of the longest and most complicated ones, so I'll start here and hopefully build out some code infrastructure that will help in fixing the other classes. Just putting my research here for easier reference. |
From the spec: 7.7.2 Transmitter PDUTable 175—Crypto Key ID recordField name Bits Data type Table 176—Transmitter PDUField size (bits) Transmitter PDU fields
48 Radio Reference ID
16 Radio Number 16-bit unsigned integer
96 Relative Antenna Location
16 Antenna Pattern Type 16-bit enumeration
16 Crypto System 16-bit enumeration Parameter records section
• • • 48 + 8K_N + 8P_N Variable Transmitter Parameters record #N
Total Transmitter PDU size = 832 + 8M + 8A + 8 sum[N, i = 1](6 + K_i + P_i) bits 6.2.8 Antenna Pattern recordTable 31—Beam Antenna Pattern recordField size (bits) Field name Data type
6.2.59 Modulation Type recordTable 90—Spread spectrum field definitionField Name Bit Value Table 91—Modulation Type recordField size (bits) Field name Data type 6.2.95 Variable Transmitter Parameters recordTable 130—Variable Transmitter Parameters recordField size (bits) Field name Data type Annex CTable C.3—Basic HAVE QUICK MP recordField size (bits) Field name Data type Table C.4—High-Fidelity HAVE QUICK VTP recordField size (bits) Field name Data type Table C.5—NET ID recordField Bits Value |
Handling Record TypesThe tricky part here:
This also implies we need some kind of mapping of the Variable Record Type enum values [UID 66] to the relevant classes. |
Handling bitfieldsNET ID Record poses another difficulty, which is echoed in many places in dis7.py: handling bitfields. The canonical way of doing so in python is using the ctypes module, which enables defining bitfield classes as subclasses of
Instantiating a This means, for NET ID, we need to:
The I will likely add a |
NamespacingLooking at the number of classes in [UID 66] I am disheartened thinking about the number of new classes I will have to dump into dis7.py, which is already hitting 8k LOC. It is already difficult trying to differentiate the various kinds of records. Very tempted to organise records into a separate module/file, with bitfields separated into their own submodule so that the dependency relation is clearer. Something like:
|
Back to this, it implies a call like Adding |
Options for parsing2-step process using marshallingExample: raw = inputStream.read_bytes(NetId.marshalledSize())
record = NetId.from_bytes(raw) Bitfield.parse(stream) class methodExample: class NetId(ctypes.Structure):
_fields_ = [...]
@classmethod
def parse(cls, stream):
raw_bytes = stream.read(cls.marshalledSize())
return cls.from_bytes(raw_bytes)
...
record = NetId.parse(inputStream) The second option has one more layer of indirection, but is a simpler call. I might create a |
A small hiccup: The fields of a This means instead of having records subclass Structure, it might be be safer to use composition instead; bitfield records might hold a non-public reference to an underlying Structure that is used to unpack bytes into values, before the record class wraps those values in appropriate types. A direct implication is that each bitfield record could require two class definitions: one for the record, and one for the |
Other bitfield classes required:
|
Variable Record types[UID 66] also maps a few variable record types, with a common Enum | Class Name
|
This is a placeholder issue for work relating to boundary padding.
Classes requiring boundary padding
To date, from a quick search in the codebase, the following classes require padding to bit boundaries (Note: not a complete list):
There is some code in VariableDatum for doing this. Ideally the process for doing so should be standardised across all of the above classes. Some helper functions would also help in this area.
Issues affected
This might potentially resolve #12 (since DataPdu composes VariableDatum)
The text was updated successfully, but these errors were encountered: