The extension block is structured thustly:
The "<headlen>" part is simply "<len>" - "<paylen>" so it is not stored. Likewise, we store only the beginning of the payload, the base can be computed if needed.
All those pointers refer DIRECTLY to the message we received, so naturally one MUST NOT alter the data we can read or we would corrupt the messages before forwarding them.
There is a slight complication introduced with GGEP extensions, since the data there can be COBS encoded, and even deflated. Therefore, reading directly data from ext_phys_payload could yield compressed data, not something really usable.
Therefore, the extension structure is mostly private, and routines are provided to access the data. Decompression and decoding of COBS is lazily performed when they wish to access the extension data.
The ext_phys_xxx fields refer to the physical information about the extension. The ext_xxx() routines allow access to the virtual information after decompression and COBS decoding. Naturally, if the extension is not compressed nor COBS-encoded, the ext_xxx() routine will return the physical data.
The structure here refers to the opaque data that is dynamically allocated each time a new extension is found.
Data Fields | |
gchar * | ext_phys_payload |
Start of payload buffer. | |
gchar * | ext_payload |
"virtual" payload | |
guint16 | ext_phys_len |
Extension length (header + payload). | |
guint16 | ext_phys_paylen |
Extension payload length. | |
guint16 | ext_paylen |
"virtual" payload length | |
guint16 | ext_rpaylen |
Length of buffer for "virtual" payload. | |
union { | |
struct { | |
gboolean extu_cobs | |
gboolean extu_deflate | |
const gchar * extu_id | |
} extu_ggep | |
} | ext_u |
|
"virtual" payload length
|
|
"virtual" payload
|
|
Extension length (header + payload).
|
|
Extension payload length.
|
|
Start of payload buffer.
|
|
Length of buffer for "virtual" payload.
|
|
|
|
Payload is COBS-encoded.
|
|
Payload is deflated.
|
|
|
|
Extension ID.
|