You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is there any valid reason for splitting the 64 bit timestamp into two separate 32 bit values? Several 64 bit fields already exist in the spec, such as the Section Length field of SHB and epb_dropcount option. Also, please note that if we would require the pcapng spec to be big-endian only then we wouldn't need to make this type of differentiation.
My recommendation is that the timestamp should be serialized as a single 64 bit value rather than as two 32 bit values.
The text was updated successfully, but these errors were encountered:
erik4711
changed the title
Comments on 4.3. Enhanced Packet Block - Specify timestamps as a 64 bit vaule
Comments on 4.3. Enhanced Packet Block - specify timestamps as a 64 bit vaule
Nov 22, 2016
4.3. Enhanced Packet Block
Is there any valid reason for splitting the 64 bit timestamp into two separate 32 bit values? Several 64 bit fields already exist in the spec, such as the Section Length field of SHB and epb_dropcount option. Also, please note that if we would require the pcapng spec to be big-endian only then we wouldn't need to make this type of differentiation.
My recommendation is that the timestamp should be serialized as a single 64 bit value rather than as two 32 bit values.
The text was updated successfully, but these errors were encountered: